Re: Any SML coders able to translate this to Python?

[Chris Angelico]

On Thu, Sep 6, 2018 at 2:29 PM, Marko Rauhamaa  wrote:
> Marko Rauhamaa  (Marko Rauhamaa):
>> Steven D'Aprano :
>>> I have this snippet of SML code which I'm trying to translate to Python:
>>>
>>> fun isqrt n = if n=0 then 0
>>>  else let val r = isqrt (n/4)
>>>   in
>>> if n < (2*r+1)^2 then 2*r
>>> else 2*r+1
>>>   end
>> [...]
>> You must make sure "r" doesn't leak outside its syntactic context so:
>>
>> def isqrt(n):
>> if n == 0:
>> return 0
>> else:
>> def f2398478957():
>> r = isqrt(n//4)
>> if n < (2*r+1)**2:
>> return 2*r
>> else:
>> return 2*r+1
>> return f2398478957()
>
> Actually, this is a more direct translation:
>
>def isqrt(n):
>if n == 0:
>return 0
>else:
>def f2398478957(r):
>if n < (2*r+1)**2:
>return 2*r
>else:
>return 2*r+1
>return f2398478957(isqrt(n//4))
>

I don't understand why you created that nested function instead of
something simple like renaming the variable. Is there a difference
here?

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

Re: Any SML coders able to translate this to Python?

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Sep 6, 2018 at 2:29 PM, Marko Rauhamaa  wrote:
>> Marko Rauhamaa  (Marko Rauhamaa):
>>> Steven D'Aprano :
 I have this snippet of SML code which I'm trying to translate to Python:

 fun isqrt n = if n=0 then 0
  else let val r = isqrt (n/4)
   in
 if n < (2*r+1)^2 then 2*r
 else 2*r+1
   end
>>> [...]
>>> You must make sure "r" doesn't leak outside its syntactic context so:
>>>
>>> def isqrt(n):
>>> if n == 0:
>>> return 0
>>> else:
>>> def f2398478957():
>>> r = isqrt(n//4)
>>> if n < (2*r+1)**2:
>>> return 2*r
>>> else:
>>> return 2*r+1
>>> return f2398478957()
>>
>> Actually, this is a more direct translation:
>>
>>def isqrt(n):
>>if n == 0:
>>return 0
>>else:
>>def f2398478957(r):
>>if n < (2*r+1)**2:
>>return 2*r
>>else:
>>return 2*r+1
>>return f2398478957(isqrt(n//4))
>>
>
> I don't understand why you created that nested function instead of
> something simple like renaming the variable. Is there a difference
> here?

Yes, in understanding the semantics of "let."

"let" is used to introduce local bindings in some functional programming
languages. I must admit I'm not fully versed in ML but it looks like the
analogue in Lisp variants. This is how the above function would be
written in Scheme:

   (define (isqrt n)
  (if (= n 0)
  0
  (let ((r (isqrt (quotient n 4
(if (< n (expt (1+ (* 2 r)) 2))
(* 2 r)
(1+ (* 2 r))

Now, Lisp's "let" can be implemented/defined using "lambda":

   (let ((X A) (Y B) ...) . BODY)

   =>

   ((lambda (X Y ...) . BODY) A B ...)

which gives us:

   (define (isqrt n)
  (if (= n 0)
  0
  ((lambda (r)
(if (< n (expt (1+ (* 2 r)) 2))
(* 2 r)
(1+ (* 2 r
   (isqrt (quotient n 4)

Python does have a limited form of "lambda" and even a conditional
expression so--as others have mentioned--this particular function could
be translated pretty directly into Python using its lambda.

More generally and idiomatically, though, Python's functions are named.
So that explains the version I give above.


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

Re: Any SML coders able to translate this to Python?

[Chris Angelico]

On Thu, Sep 6, 2018 at 6:44 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Thu, Sep 6, 2018 at 2:29 PM, Marko Rauhamaa  wrote:
>>> Marko Rauhamaa  (Marko Rauhamaa):
 Steven D'Aprano :
> I have this snippet of SML code which I'm trying to translate to Python:
>
> fun isqrt n = if n=0 then 0
>  else let val r = isqrt (n/4)
>   in
> if n < (2*r+1)^2 then 2*r
> else 2*r+1
>   end
 [...]
 You must make sure "r" doesn't leak outside its syntactic context so:

 def isqrt(n):
 if n == 0:
 return 0
 else:
 def f2398478957():
 r = isqrt(n//4)
 if n < (2*r+1)**2:
 return 2*r
 else:
 return 2*r+1
 return f2398478957()
>>>
>>> Actually, this is a more direct translation:
>>>
>>>def isqrt(n):
>>>if n == 0:
>>>return 0
>>>else:
>>>def f2398478957(r):
>>>if n < (2*r+1)**2:
>>>return 2*r
>>>else:
>>>return 2*r+1
>>>return f2398478957(isqrt(n//4))
>>>
>>
>> I don't understand why you created that nested function instead of
>> something simple like renaming the variable. Is there a difference
>> here?
>
> Yes, in understanding the semantics of "let."
>
> "let" is used to introduce local bindings in some functional programming
> languages. I must admit I'm not fully versed in ML but it looks like the
> analogue in Lisp variants. This is how the above function would be
> written in Scheme:
>
>(define (isqrt n)
>   (if (= n 0)
>   0
>   (let ((r (isqrt (quotient n 4
> (if (< n (expt (1+ (* 2 r)) 2))
> (* 2 r)
> (1+ (* 2 r))
>
> Now, Lisp's "let" can be implemented/defined using "lambda":
>
>(let ((X A) (Y B) ...) . BODY)
>
>=>
>
>((lambda (X Y ...) . BODY) A B ...)
>
> which gives us:
>
>(define (isqrt n)
>   (if (= n 0)
>   0
>   ((lambda (r)
> (if (< n (expt (1+ (* 2 r)) 2))
> (* 2 r)
> (1+ (* 2 r
>(isqrt (quotient n 4)
>
> Python does have a limited form of "lambda" and even a conditional
> expression so--as others have mentioned--this particular function could
> be translated pretty directly into Python using its lambda.
>
> More generally and idiomatically, though, Python's functions are named.
> So that explains the version I give above.

And even more idiomatically, Python doesn't require a new scope just
for a new variable. So a much more idiomatic translation would be to
simply ensure that the inner variable can't collide, and then ignore
the function boundary. And I'm not sure if there even is a name
collision. What's the issue with scoping at all here? What's the inner
function actually achieving?

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

Re: Any SML coders able to translate this to Python?

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Sep 6, 2018 at 6:44 PM, Marko Rauhamaa  wrote:
> And even more idiomatically, Python doesn't require a new scope just
> for a new variable. So a much more idiomatic translation would be to
> simply ensure that the inner variable can't collide, and then ignore
> the function boundary. And I'm not sure if there even is a name
> collision. What's the issue with scoping at all here? What's the inner
> function actually achieving?

We can debate what the inner function is achieving. The main point is
that functional languages create an inner function for each "let"
statement. Steve was wondering what "let" meant, and the Python code--I
hope--helped illustrate it.

Typical Scheme code is riddled with inner functions. Local variables?
An inner function. A loop? An inner function. Exception handling? An
inner function.

Scheme can also be written procedurally through macros, but those macros
generate inner functions.


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

Re: Any SML coders able to translate this to Python?

[Antoon Pardon]

On 06-09-18 10:50, Chris Angelico wrote:
> On Thu, Sep 6, 2018 at 6:44 PM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>
>>> On Thu, Sep 6, 2018 at 2:29 PM, Marko Rauhamaa  wrote:
 Marko Rauhamaa  (Marko Rauhamaa):
> Steven D'Aprano :
>> I have this snippet of SML code which I'm trying to translate to Python:
>>
>> fun isqrt n = if n=0 then 0
>>  else let val r = isqrt (n/4)
>>   in
>> if n < (2*r+1)^2 then 2*r
>> else 2*r+1
>>   end
> [...]
> You must make sure "r" doesn't leak outside its syntactic context so:
>
> def isqrt(n):
> if n == 0:
> return 0
> else:
> def f2398478957():
> r = isqrt(n//4)
> if n < (2*r+1)**2:
> return 2*r
> else:
> return 2*r+1
> return f2398478957()
 Actually, this is a more direct translation:

def isqrt(n):
if n == 0:
return 0
else:
def f2398478957(r):
if n < (2*r+1)**2:
return 2*r
else:
return 2*r+1
return f2398478957(isqrt(n//4))

>>> I don't understand why you created that nested function instead of
>>> something simple like renaming the variable. Is there a difference
>>> here?
>> Yes, in understanding the semantics of "let."
>>
>> "let" is used to introduce local bindings in some functional programming
>> languages. I must admit I'm not fully versed in ML but it looks like the
>> analogue in Lisp variants. This is how the above function would be
>> written in Scheme:
>>
>>(define (isqrt n)
>>   (if (= n 0)
>>   0
>>   (let ((r (isqrt (quotient n 4
>> (if (< n (expt (1+ (* 2 r)) 2))
>> (* 2 r)
>> (1+ (* 2 r))
>>
>> Now, Lisp's "let" can be implemented/defined using "lambda":
>>
>>(let ((X A) (Y B) ...) . BODY)
>>
>>=>
>>
>>((lambda (X Y ...) . BODY) A B ...)
>>
>> which gives us:
>>
>>(define (isqrt n)
>>   (if (= n 0)
>>   0
>>   ((lambda (r)
>> (if (< n (expt (1+ (* 2 r)) 2))
>> (* 2 r)
>> (1+ (* 2 r
>>(isqrt (quotient n 4)
>>
>> Python does have a limited form of "lambda" and even a conditional
>> expression so--as others have mentioned--this particular function could
>> be translated pretty directly into Python using its lambda.
>>
>> More generally and idiomatically, though, Python's functions are named.
>> So that explains the version I give above.
> And even more idiomatically, Python doesn't require a new scope just
> for a new variable.

You may have overlooked where Marko wrote:
Actually, this is a more *direct* translation

-- 
Antoon.



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

Re: Any SML coders able to translate this to Python?

[Chris Angelico]

On Thu, Sep 6, 2018 at 7:22 PM, Antoon Pardon  wrote:
> On 06-09-18 10:50, Chris Angelico wrote:
>> On Thu, Sep 6, 2018 at 6:44 PM, Marko Rauhamaa  wrote:
>>> Chris Angelico :
>>>
 On Thu, Sep 6, 2018 at 2:29 PM, Marko Rauhamaa  wrote:
> Marko Rauhamaa  (Marko Rauhamaa):
>> Steven D'Aprano :
>>> I have this snippet of SML code which I'm trying to translate to Python:
>>>
>>> fun isqrt n = if n=0 then 0
>>>  else let val r = isqrt (n/4)
>>>   in
>>> if n < (2*r+1)^2 then 2*r
>>> else 2*r+1
>>>   end
>> [...]
>> You must make sure "r" doesn't leak outside its syntactic context so:
>>
>> def isqrt(n):
>> if n == 0:
>> return 0
>> else:
>> def f2398478957():
>> r = isqrt(n//4)
>> if n < (2*r+1)**2:
>> return 2*r
>> else:
>> return 2*r+1
>> return f2398478957()
> Actually, this is a more direct translation:
>
>def isqrt(n):
>if n == 0:
>return 0
>else:
>def f2398478957(r):
>if n < (2*r+1)**2:
>return 2*r
>else:
>return 2*r+1
>return f2398478957(isqrt(n//4))
>
 I don't understand why you created that nested function instead of
 something simple like renaming the variable. Is there a difference
 here?
>>> Yes, in understanding the semantics of "let."
>>>
>>> "let" is used to introduce local bindings in some functional programming
>>> languages. I must admit I'm not fully versed in ML but it looks like the
>>> analogue in Lisp variants. This is how the above function would be
>>> written in Scheme:
>>>
>>>(define (isqrt n)
>>>   (if (= n 0)
>>>   0
>>>   (let ((r (isqrt (quotient n 4
>>> (if (< n (expt (1+ (* 2 r)) 2))
>>> (* 2 r)
>>> (1+ (* 2 r))
>>>
>>> Now, Lisp's "let" can be implemented/defined using "lambda":
>>>
>>>(let ((X A) (Y B) ...) . BODY)
>>>
>>>=>
>>>
>>>((lambda (X Y ...) . BODY) A B ...)
>>>
>>> which gives us:
>>>
>>>(define (isqrt n)
>>>   (if (= n 0)
>>>   0
>>>   ((lambda (r)
>>> (if (< n (expt (1+ (* 2 r)) 2))
>>> (* 2 r)
>>> (1+ (* 2 r
>>>(isqrt (quotient n 4)
>>>
>>> Python does have a limited form of "lambda" and even a conditional
>>> expression so--as others have mentioned--this particular function could
>>> be translated pretty directly into Python using its lambda.
>>>
>>> More generally and idiomatically, though, Python's functions are named.
>>> So that explains the version I give above.
>> And even more idiomatically, Python doesn't require a new scope just
>> for a new variable.
>
> You may have overlooked where Marko wrote:
> Actually, this is a more *direct* translation

That was *after* stating this:

> You must make sure "r" doesn't leak outside its syntactic context so:

Why "must"? The request was to translate this into Python, not to
slavishly imitate every possible semantic difference even if it won't
actually affect behaviour. If there were some way in which the name
actually HAD to be kept scoped in, then sure - maybe a name collision
or something - but I can't see that here. So by insisting that the
translation maintain an unnecessary inner function, Marko is
distracting from a logical and semantic translation of the behaviour
of the function.

Unless I'm missing something, and there actually IS a good reason for
the inner function, other than "well, that's how it works in the
source language".

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

Debug script under pdb, how to avoid a bunch of errors caused by the exit()?

[Jach Fong]

Here the script file, test0.py:
--
password = 'bad'
if password == 'bad':
print('bad password')
exit()
else:
print('good password')

print('something else to do')


When running it under Python3.4 Windows Vista, no problem at all.

D:\Works\Python>py test0.py
bad password

But if debug it under pdb:

D:\Works\Python>py -m pdb test0.py
> d:\works\python\test0.py(1)()
-> password = 'bad'
(Pdb) tbreak 3
Breakpoint 1 at d:\works\python\test0.py:3
(Pdb) cont
Deleted breakpoint 1 at d:\works\python\test0.py:3
> d:\works\python\test0.py(3)()
-> print('bad password')
(Pdb) cont
bad password
The program exited via sys.exit(). Exit status: None
> d:\works\python\test0.py(1)()
-> password = 'bad'
(Pdb) Traceback (most recent call last):
  File "C:\Python34\lib\pdb.py", line 1661, in main
pdb._runscript(mainpyfile)
  File "C:\Python34\lib\pdb.py", line 1542, in _runscript
self.run(statement)
  File "C:\Python34\lib\bdb.py", line 431, in run
exec(cmd, globals, locals)
  File "", line 1, in 
  File "d:\works\python\test0.py", line 1, in 
password = 'bad'
  File "d:\works\python\test0.py", line 1, in 
password = 'bad'
  File "C:\Python34\lib\bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
  File "C:\Python34\lib\bdb.py", line 66, in dispatch_line
self.user_line(frame)
  File "C:\Python34\lib\pdb.py", line 259, in user_line
self.interaction(frame, None)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
line = input(self.prompt)
ValueError: I/O operation on closed file.
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\python34\lib\cmd.py(126)cmdloop()
-> line = input(self.prompt)
(Pdb) Traceback (most recent call last):
  File "C:\Python34\lib\pdb.py", line 1661, in main
pdb._runscript(mainpyfile)
  File "C:\Python34\lib\pdb.py", line 1542, in _runscript
self.run(statement)
  File "C:\Python34\lib\bdb.py", line 431, in run
exec(cmd, globals, locals)
  File "", line 1, in 
  File "d:\works\python\test0.py", line 1, in 
password = 'bad'
  File "d:\works\python\test0.py", line 1, in 
password = 'bad'
  File "C:\Python34\lib\bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
  File "C:\Python34\lib\bdb.py", line 66, in dispatch_line
self.user_line(frame)
  File "C:\Python34\lib\pdb.py", line 259, in user_line
self.interaction(frame, None)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
line = input(self.prompt)
ValueError: I/O operation on closed file.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python34\lib\runpy.py", line 170, in _run_module_as_main
"__main__", mod_spec)
  File "C:\Python34\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "C:\Python34\lib\pdb.py", line 1688, in 
pdb.main()
  File "C:\Python34\lib\pdb.py", line 1680, in main
pdb.interaction(None, t)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
line = input(self.prompt)
ValueError: I/O operation on closed file.

D:\Works\Python>

How to get rid of these?

Best Regards,
Jach Fong


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: Any SML coders able to translate this to Python?

[Marko Rauhamaa]

Chris Angelico :
> The request was to translate this into Python, not to slavishly
> imitate every possible semantic difference even if it won't actually
> affect behaviour.

I trust Steven to be able to refactor the code into something more
likable. His only tripping point was the meaning of the "let" construct.


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

Re: CURSES WINDOWS

[Anssi Saari]

Peter via Python-list  writes:

>>     from _curses import *
>> ModuleNotFoundError: No module named '_curses'

Oh yes, I tested in Cygwin and maybe it doesn't count? But for Windows
there's a curses wheel available at
https://www.lfd.uci.edu/~gohlke/pythonlibs/#curses

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

fsxNet Usenet gateway problem again

[Michael Torrie]

On 09/05/2018 02:30 PM, Chris Angelico wrote:
> I don't think this was spamming the list with the same question; a
> glitch somewhere in a netnews server appears to be re-posting some old
> posts.

I wonder why this bbs gateway in New Zealand keeps doing this.  Seems
like someone contacts the postmaster there and he fixes the problem, and
then it keeps coming back.  Configuration gets reverted?
-- 
https://mail.python.org/mailman/listinfo/python-list

Object-oriented philosophy

[Michael F. Stemper]

Over the summer, I've been working on a simulation. After months
of design and redesign, I finally coded it up in two days over
Labor Day weekend. Works great.

The core of the simulation is a set of models of three different
types of electrical loads (characterized based on how they respond
to voltage changes), implemented as python classes.

Since the three classes all had common methods (by design), I
thought that maybe refactoring these three classes to inherit from
a parent class would be beneficial. I went ahead and did so.
(Outlines of before and after are at the end of the post.)

Net net is that the only thing that ended up being common was the
__init__ methods. Two of the classes have identical __init__
methods; the third has a superset of that method. The other methods
all have completely different implementations. This isn't due to
poor coding, but due to the fact that what these model have
different physical characteristics.

Not being that familiar with object-oriented programming (I grew up
on FORTRAN and c), I'm seeking opinions:

Is there really any benefit to this change? Yes, I've eliminated
some (a few lines per class) duplicate code. On the other hand,
I've added the parent class and the (probably small, but not
non-existent) overhead of invoking super().

How does one judge when it's worthwhile to do this and when it's
not? What criteria would somebody seasoned in OO and python use
to say "good idea" vs "don't waste your time"?

Other thoughts on this topic would also be appreciated.


Comparison follows:

= begin original 
class ConstantPower( ):
  def __init__( self, xmlmodel, V ):
  def Resistance( self, V ):
  def Power( self, V ):
  def FixedValue( self ):
class ConstantCurrent( ):
  def __init__( self, xmlmodel, V ):
  def Resistance( self, V ):
  def Power( self, V ):
  def FixedValue( self ):
class ConstantImpedance( ):
  def __init__( self, xmlmodel, V ):
  def Resistance( self, V ):
  def Power( self, V ):
  def FixedValue( self ):
  def Update( self, V ):
=== end original 

= begin revised =
class LoadModel( ):
  def __init__( self, xmlmodel, V, id ):
class ConstantPower( LoadModel ):
  def __init__( self, xmlmodel, V ):
super().__init__( xmlmodel, V, "constant power" )
  def Resistance( self, V ):
  def Power( self, V ):
  def FixedValue( self ):
class ConstantCurrent( LoadModel ):
  def __init__( self, xmlmodel, V ):
super().__init__( xmlmodel, V, "constant current" )
  def Resistance( self, V ):
  def Power( self, V ):
  def FixedValue( self ):
class ConstantImpedance( LoadModel ):
  def __init__( self, xmlmodel, V ):
super().__init__( xmlmodel, V, self.name )
  def Resistance( self, V ):
  def Power( self, V ):
  def FixedValue( self ):
  def Update( self, V ):
=== end revised =

-- 
Michael F. Stemper
This email is to be read by its intended recipient only. Any other party
reading is required by the EULA to send me $500.00.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Object-oriented philosophy

[Marko Rauhamaa]

"Michael F. Stemper" :

> Since the three classes all had common methods (by design), I
> thought that maybe refactoring these three classes to inherit from
> a parent class would be beneficial. I went ahead and did so.
> (Outlines of before and after are at the end of the post.)
>
> Net net is that the only thing that ended up being common was the
> __init__ methods. Two of the classes have identical __init__
> methods; the third has a superset of that method. The other methods
> all have completely different implementations. This isn't due to
> poor coding, but due to the fact that what these model have
> different physical characteristics.
>
> [...]
>
> Is there really any benefit to this change? Yes, I've eliminated
> some (a few lines per class) duplicate code. On the other hand,
> I've added the parent class and the (probably small, but not
> non-existent) overhead of invoking super().
>
> How does one judge when it's worthwhile to do this and when it's
> not? What criteria would somebody seasoned in OO and python use
> to say "good idea" vs "don't waste your time"?

Ultimately, a seasoned OO programmer might prefer one structure in the
morning and another structure in the afternoon.

Python's ducktyping makes it possible to develop classes to an interface
that is not spelled out as a base class. My opinion is that you should
not define base classes only to show pedigree as you would need to in,
say, Java.

Then, is it worthwhile to define a base class just to avoid typing the
same constructor twice? That's a matter of opinion. You can go either
way. Just understand that the base class doesn't serve a philosophical
role but is simply an implementation utility. Be prepared to refactor
the code and get rid of the base class the moment the commonality
disappears.

On the other hand, why is it that the two constructors happen to
coincide? Is it an indication that the two classes have something deeper
in common that the third one doesn't? If it is not a coincidence, go
ahead and give the base class a name that expresses the commonality.

Don't be afraid of "wasting your time" or worry too much about whether
something is a "good idea." Be prepared to massage the code over time as
your understanding and tastes evolve.


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

EuroPython 2018: Videos for Friday available

[M.-A. Lemburg]

We are pleased to announce the third and last batch of cut videos from
EuroPython 2018 in Edinburgh, Scotland, UK.

 * EuroPython 2018 YouTube Playlist *

https://www.youtube.com/watch?v=UXSr1OL5JKo&t=0s&index=130&list=PL8uoeex94UhFrNUV2m5MigREebUms39U5


In the last batch, we have included all videos for Friday, July 27
2018, the third conference day.

In total, we now have more than 130 videos available for you to watch.

All EuroPython videos, including the ones from previous conferences,
are available on our EuroPython YouTube Channel.

http://europython.tv/


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/177798571707/europython-2018-videos-for-friday-available

Tweet:

https://twitter.com/europython/status/1037666146147811328


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/

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

Re: Object-oriented philosophy

[Rhodri James]

On 06/09/18 15:04, Michael F. Stemper wrote:

Net net is that the only thing that ended up being common was the
__init__ methods. Two of the classes have identical __init__
methods; the third has a superset of that method. The other methods
all have completely different implementations. This isn't due to
poor coding, but due to the fact that what these model have
different physical characteristics.

Not being that familiar with object-oriented programming (I grew up
on FORTRAN and c), I'm seeking opinions:

Is there really any benefit to this change? Yes, I've eliminated
some (a few lines per class) duplicate code. On the other hand,
I've added the parent class and the (probably small, but not
non-existent) overhead of invoking super().


What you've done is the work you would have to do in a statically-typed 
language such as C++.  You've been taking advantage of duck typing to 
have the rest of your code not have to care about what type of load you 
are modelling, but in C++ (say) you would need the superclass to supply 
the type information to let the rest of your code compile.


Is it worth creating the superclass in Python?  It sounds like it's a 
bit marginal in your case.  I'm not that seasoned in object-oriented 
design either, but my yardstick would be how much common code does it 
eliminate?  It's a very subjective measure, but basically it's the same 
subjective measure as for pulling any common code into a separate function.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Object-oriented philosophy

[Abdur-Rahmaan Janhangeer]

Also, get someone, preferrable a python engineer to review your code.

yours,

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: fsxNet Usenet gateway problem again

[Thomas Jollans]

On 2018-09-06 15:50, Michael Torrie wrote:
> On 09/05/2018 02:30 PM, Chris Angelico wrote:
>> I don't think this was spamming the list with the same question; a
>> glitch somewhere in a netnews server appears to be re-posting some old
>> posts.
> 
> I wonder why this bbs gateway in New Zealand keeps doing this.  Seems
> like someone contacts the postmaster there and he fixes the problem, and
> then it keeps coming back.  Configuration gets reverted?
> 

I love that the reposted messages come with a header

Path: uni-berlin.de!<...>!.POSTED.agency.bbs.nz!not-for-mail
   ^

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

OpenSSL error

[Peng Yu]

Hi,

I got the following error. Does anybody know how to fix it? Thanks.

$ pip
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/bin/pip",
line 7, in 
from pip._internal import main
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/_internal/__init__.py",
line 42, in 
from pip._internal import cmdoptions
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/_internal/cmdoptions.py",
line 16, in 
from pip._internal.index import (
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/_internal/index.py",
line 14, in 
from pip._vendor import html5lib, requests, six
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py",
line 97, in 
from pip._vendor.urllib3.contrib import pyopenssl
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/_vendor/urllib3/contrib/pyopenssl.py",
line 46, in 
import OpenSSL.SSL
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenSSL/__init__.py",
line 8, in 
from OpenSSL import rand, crypto, SSL
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenSSL/SSL.py",
line 118, in 
SSL_ST_INIT = _lib.SSL_ST_INIT
AttributeError: 'module' object has no attribute 'SSL_ST_INIT'


-- 
Regards,
Peng
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Debug script under pdb, how to avoid a bunch of errors caused by the exit()?

[Oscar Benjamin]

On Thu, 6 Sep 2018 at 10:59, Jach Fong  wrote:
>
>  Here the script file, test0.py:
> --
> password = 'bad'
> if password == 'bad':
>  print('bad password')
>  exit()
> else:
>  print('good password')
>
> print('something else to do')
> 
>
>  When running it under Python3.4 Windows Vista, no problem at all.
>
> D:\Works\Python>py test0.py
> bad password
>
>  But if debug it under pdb:
>
> D:\Works\Python>py -m pdb test0.py
> [...]
> ValueError: I/O operation on closed file.
> Uncaught exception. Entering post mortem debugging
>
>  How to get rid of these?

I haven't noticed this behaviour before but then I normally use
functions rather than writing my code at top level and quitting with
exit(). If I had written your script then it might look something
like:

def main():
password = 'bad'
if password == 'bad':
print('bad password')
return  # <-- Not exit()
else:
print('good password')

print('something else to do')

if __name__ == "__main__":
main()

Now since you're no longer using exit() to end the program it doesn't
need to screw up pdb.

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

Why emumerated list is empty on 2nd round of print?

[Viet Nguyen via Python-list]

>>> numList
[2, 7, 22, 30, 1, 8]

>>> aList = enumerate(numList)

>>> for i,j in aList:print(i,j)

0 2
1 7
2 22
3 30
4 1
5 8

>>> for i,j in aList:print(i,j)

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

Re: Why emumerated list is empty on 2nd round of print?

[Chris Angelico]

On Fri, Sep 7, 2018 at 3:26 AM, Viet Nguyen via Python-list
 wrote:
 numList
> [2, 7, 22, 30, 1, 8]
>
 aList = enumerate(numList)
>
 for i,j in aList:print(i,j)
>
> 0 2
> 1 7
> 2 22
> 3 30
> 4 1
> 5 8
>
 for i,j in aList:print(i,j)
>


Because it's not an enumerated list, it's an enumerated iterator.
Generally, you'll just use that directly in the loop:

for i, value in enumerate(numbers):

There's generally no need to hang onto it from one loop to another.

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

Re: Why emumerated list is empty on 2nd round of print?

[Viet Nguyen via Python-list]

On Thursday, September 6, 2018 at 10:34:19 AM UTC-7, Chris Angelico wrote:
> On Fri, Sep 7, 2018 at 3:26 AM, Viet Nguyen via Python-list
>  wrote:
>  numList
> > [2, 7, 22, 30, 1, 8]
> >
>  aList = enumerate(numList)
> >
>  for i,j in aList:print(i,j)
> >
> > 0 2
> > 1 7
> > 2 22
> > 3 30
> > 4 1
> > 5 8
> >
>  for i,j in aList:print(i,j)
> >
> 
> 
> Because it's not an enumerated list, it's an enumerated iterator.
> Generally, you'll just use that directly in the loop:
> 
> for i, value in enumerate(numbers):
> 
> There's generally no need to hang onto it from one loop to another.
> 
> ChrisA

Thanks ChrisA. If I do this "aList = enumerate(numList)", isn't it stored 
permanently in aList now?  I see your point to use it directly, but just in 
case I do need to hang onto it from one loop to another, then how is that done? 
  Anyway I think I'm ok and I got what I need for now.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Why emumerated list is empty on 2nd round of print?

[David Raymond]

The actual "enumerate" object is really just holding a current index and a 
reference to the original list. So if you alter the original list while you're 
iterating through it you'll see the changes. If you want a full copy then you 
can just wrap it with list()

Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> numList = [2, 7, 22, 30, 1, 8]
>>> aList = enumerate(numList)
>>> aList.__next__()
(0, 2)
>>> numList[1] = 5
>>> aList.__next__()
(1, 5)
>>> aList2 = list(enumerate(numList))
>>> aList2
[(0, 2), (1, 5), (2, 22), (3, 30), (4, 1), (5, 8)]
>>> numList[3] = -12
>>> aList2
[(0, 2), (1, 5), (2, 22), (3, 30), (4, 1), (5, 8)]
>>> aList.__next__()
(2, 22)
>>> aList.__next__()
(3, -12)
>>> aList.__next__()
(4, 1)
>>> aList.__next__()
(5, 8)
>>> aList.__next__()
Traceback (most recent call last):
  File "", line 1, in 
StopIteration
>>>


-Original Message-
From: Python-list 
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
Viet Nguyen via Python-list
Sent: Thursday, September 06, 2018 2:50 PM
To: python-list@python.org
Subject: Re: Why emumerated list is empty on 2nd round of print?

On Thursday, September 6, 2018 at 10:34:19 AM UTC-7, Chris Angelico wrote:
> On Fri, Sep 7, 2018 at 3:26 AM, Viet Nguyen via Python-list
>  wrote:
>  numList
> > [2, 7, 22, 30, 1, 8]
> >
>  aList = enumerate(numList)
> >
>  for i,j in aList:print(i,j)
> >
> > 0 2
> > 1 7
> > 2 22
> > 3 30
> > 4 1
> > 5 8
> >
>  for i,j in aList:print(i,j)
> >
> 
> 
> Because it's not an enumerated list, it's an enumerated iterator.
> Generally, you'll just use that directly in the loop:
> 
> for i, value in enumerate(numbers):
> 
> There's generally no need to hang onto it from one loop to another.
> 
> ChrisA

Thanks ChrisA. If I do this "aList = enumerate(numList)", isn't it stored 
permanently in aList now?  I see your point to use it directly, but just in 
case I do need to hang onto it from one loop to another, then how is that done? 
  Anyway I think I'm ok and I got what I need for now.
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why emumerated list is empty on 2nd round of print?

[Chris Angelico]

On Fri, Sep 7, 2018 at 4:50 AM, Viet Nguyen via Python-list
 wrote:
>> Because it's not an enumerated list, it's an enumerated iterator.
>> Generally, you'll just use that directly in the loop:
>>
>> for i, value in enumerate(numbers):
>>
>> There's generally no need to hang onto it from one loop to another.
>>
>> ChrisA
>
> Thanks ChrisA. If I do this "aList = enumerate(numList)", isn't it stored 
> permanently in aList now?  I see your point to use it directly, but just in 
> case I do need to hang onto it from one loop to another, then how is that 
> done?   Anyway I think I'm ok and I got what I need for now.
>

The enumerator is. It doesn't become something different when you
assign it to something. Assume you don't need to hang onto it, until
such time as that changes. :)

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

don't quite understand mailing list

[VanDyk, Richard T]

Greetings;
I sent in a question on how to install robot framework on python 3.7 using pip 
(or any other way). None of the commands on the >>> seem to work for me. I was 
asked to update the c/c++ runtime which I don't know what that means. I was 
also asked to subscribe to the mailing list. I did that but don't want 
everyone's submitted question to come to me.
Can you please take me off the mailing list or prevent questions from coming to 
me. Can you advise me on my problem or point me in the right direction?
Thanks.

Richard VanDyk
Software Contractor (Indotronix), Missiles and Fire Control
Lockheed Martin Corporation
1701 W Marshall Dr, Grand Prairie, TX 75051
Phone:  972-603-3303
[cid:image001.png@01D3B492.AF6B5C30]

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

Re: Object-oriented philosophy

[Thomas Jollans]

On 2018-09-06 17:40, Abdur-Rahmaan Janhangeer wrote:
> Also, get someone, preferrable a python engineer to review your code.

Does anyone here know anyone who would refer to themselves as a "Python
engineer" with a straight face? I merely ask...

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

Re: Why emumerated list is empty on 2nd round of print?

[Viet Nguyen via Python-list]

On Thursday, September 6, 2018 at 12:12:20 PM UTC-7, David Raymond wrote:
> The actual "enumerate" object is really just holding a current index and a 
> reference to the original list. So if you alter the original list while 
> you're iterating through it you'll see the changes. If you want a full copy 
> then you can just wrap it with list()
> 
> Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit 
> (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> numList = [2, 7, 22, 30, 1, 8]
> >>> aList = enumerate(numList)
> >>> aList.__next__()
> (0, 2)
> >>> numList[1] = 5
> >>> aList.__next__()
> (1, 5)
> >>> aList2 = list(enumerate(numList))
> >>> aList2
> [(0, 2), (1, 5), (2, 22), (3, 30), (4, 1), (5, 8)]
> >>> numList[3] = -12
> >>> aList2
> [(0, 2), (1, 5), (2, 22), (3, 30), (4, 1), (5, 8)]
> >>> aList.__next__()
> (2, 22)
> >>> aList.__next__()
> (3, -12)
> >>> aList.__next__()
> (4, 1)
> >>> aList.__next__()
> (5, 8)
> >>> aList.__next__()
> Traceback (most recent call last):
>   File "", line 1, in 
> StopIteration
> >>>
> 
> 
> -Original Message-
> From: Python-list 
> [mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
> Viet Nguyen via Python-list
> Sent: Thursday, September 06, 2018 2:50 PM
> To: python-list@python.org
> Subject: Re: Why emumerated list is empty on 2nd round of print?
> 
> On Thursday, September 6, 2018 at 10:34:19 AM UTC-7, Chris Angelico wrote:
> > On Fri, Sep 7, 2018 at 3:26 AM, Viet Nguyen via Python-list
> >  wrote:
> >  numList
> > > [2, 7, 22, 30, 1, 8]
> > >
> >  aList = enumerate(numList)
> > >
> >  for i,j in aList:print(i,j)
> > >
> > > 0 2
> > > 1 7
> > > 2 22
> > > 3 30
> > > 4 1
> > > 5 8
> > >
> >  for i,j in aList:print(i,j)
> > >
> > 
> > 
> > Because it's not an enumerated list, it's an enumerated iterator.
> > Generally, you'll just use that directly in the loop:
> > 
> > for i, value in enumerate(numbers):
> > 
> > There's generally no need to hang onto it from one loop to another.
> > 
> > ChrisA
> 
> Thanks ChrisA. If I do this "aList = enumerate(numList)", isn't it stored 
> permanently in aList now?  I see your point to use it directly, but just in 
> case I do need to hang onto it from one loop to another, then how is that 
> done?   Anyway I think I'm ok and I got what I need for now.
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Very clear and good examples!  Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: don't quite understand mailing list

[Reto Brunner]

On Thu, Sep 06, 2018 at 07:10:10PM +, VanDyk, Richard T wrote:
> Can you please take me off the mailing list or prevent questions from coming 
> to me. Can you advise me on my problem or point me in the right direction?
> Thanks.
> https://mail.python.org/mailman/listinfo/python-list

What do you think the link, which is attached to every email you receive
from the list, is for? Listinfo sounds very promising, doesn't it?

And if you actually go to it you'll find:
"To unsubscribe from Python-list, get a password reminder, or change your 
subscription options enter your subscription email address"

So how about you try that?
-- 
https://mail.python.org/mailman/listinfo/python-list

ModuleNotFoundError: No module named 'encodings'

[Jason Qian via Python-list]

Hi

Need some help.

I have a C++ application that invokes Python.

...
Py_SetPythonHome("python_path");
Py_Initialize();

This works fine on Python 3.6.4 version, but got errors on Python 3.7.0
when calling Py_Initialize(),

Fatal Python error: initfsencoding: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'


Thanks for the help
Jason
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Object-oriented philosophy

[Rob Gaddi]

On 09/06/2018 09:07 AM, Thomas Jollans wrote:

On 2018-09-06 17:40, Abdur-Rahmaan Janhangeer wrote:

Also, get someone, preferrable a python engineer to review your code.


Does anyone here know anyone who would refer to themselves as a "Python
engineer" with a straight face? I merely ask...

-- Thomas



Suddenly I'm filled with visions of pipe, fittings, and a herpetology 
degree.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: don't quite understand mailing list

[Ethan Furman]

On 09/06/2018 12:42 PM, Reto Brunner wrote:


What do you think the link, which is attached to every email you receive
from the list, is for? Listinfo sounds very promising, doesn't it?

And if you actually go to it you'll find:
"To unsubscribe from Python-list, get a password reminder, or change your 
subscription options enter your subscription email address"

So how about you try that?


Reto,  your response is inappropriate.  If you can't be kind and/or respectful, 
let someone else respond.

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

Re: Object-oriented philosophy

[Michael F. Stemper]

On 2018-09-06 09:34, Marko Rauhamaa wrote:
> "Michael F. Stemper" :
> 
>> Since the three classes all had common methods (by design), I
>> thought that maybe refactoring these three classes to inherit from
>> a parent class would be beneficial. I went ahead and did so.
>> (Outlines of before and after are at the end of the post.)
>>
>> Net net is that the only thing that ended up being common was the
>> __init__ methods. Two of the classes have identical __init__
>> methods; the third has a superset of that method. The other methods
>> all have completely different implementations. This isn't due to
>> poor coding, but due to the fact that what these model have
>> different physical characteristics.
>>
>> [...]
>>
>> Is there really any benefit to this change? Yes, I've eliminated
>> some (a few lines per class) duplicate code. On the other hand,
>> I've added the parent class and the (probably small, but not
>> non-existent) overhead of invoking super().
>>
>> How does one judge when it's worthwhile to do this and when it's
>> not? What criteria would somebody seasoned in OO and python use
>> to say "good idea" vs "don't waste your time"?
> 
> Ultimately, a seasoned OO programmer might prefer one structure in the
> morning and another structure in the afternoon.

I figured that was the case, which is why I sought criteria to consider
rather than a cut-and-dried answer.

> Python's ducktyping makes it possible to develop classes to an interface
> that is not spelled out as a base class.

After reviewing my code, I have a feeling that I'm not taking
advantage of duck typing. I think that if LoadList held all types
of load and I did this:

for load in LoadList:
  load.served = load.Power( Feeder.V_load )
  LoadServed += load.served

it would be duck typing. Unfortunately, I'm not. I had thought that
I needed to handle the constant power load (if there is one)
separately in at least one point, and the same for a possible
constant current load. The (zero to many) constant impedance loads
are all in a list over which I loop.

However, inspired by your point, I think that I've found a way to
handle them all in one list. I'll play with it a little.

>   My opinion is that you should
> not define base classes only to show pedigree as you would need to in,
> say, Java.

Maybe it was from what I've read about Java (zero experience) that gave
me the idea to try this.

> Then, is it worthwhile to define a base class just to avoid typing the
> same constructor twice? That's a matter of opinion. You can go either
> way. Just understand that the base class doesn't serve a philosophical
> role but is simply an implementation utility. Be prepared to refactor
> the code and get rid of the base class the moment the commonality
> disappears.

I'll keep that in mind, but the commonality is based on the laws of
physics, so it's not a big risk.

> On the other hand, why is it that the two constructors happen to
> coincide? Is it an indication that the two classes have something deeper
> in common that the third one doesn't? If it is not a coincidence, go
> ahead and give the base class a name that expresses the commonality.

The code which all three load types share, which is the total content
of their parent, is as follows:

def __init__( self, xmlmodel, V, id ):

  try:
P_0s = xmlmodel.findall( 'RatedPower' )[0].text
self.P_0 = float( P_0s )
  except:
Utility.DataErr( "Power not specified for %s load" % (id) )
  if self.P_0<=0.0:
Utility.DataErr( "Power for %s load must be postive, not %s" \
  % (id,P_0s) )


The constant impedance loads then extend this by initializing a
duty cycle model. (Think of something thermostatically controlled,
such as an electric oven or electric space heating.)

The constant impedance loads then extend this by initializing a
duty cycle model. (Think of something thermostatically controlled,
such as an electric oven or electric space heating.)

The 3-foot[1] view of the data model is:







> Don't be afraid of "wasting your time"

If was was afraid of that, I wouldn't have tried refactoring the code
in the first place. I would have said "it works, don't bother."

>   or worry too much about whether
> something is a "good idea."

Well, if it turns out to be a bad idea, I'd rather learn that it's a
bad idea.

>   Be prepared to massage the code over time as
> your understanding and tastes evolve.

Exactly what I was doing, and the point of asking was to extend my
understanding.

Thanks for taking the time to respond.

-- 
Michael F. Stemper
What happens if you play John Cage's "4'33" at a slower tempo?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Object-oriented philosophy

[Michael F. Stemper]

On 2018-09-06 09:35, Rhodri James wrote:
> On 06/09/18 15:04, Michael F. Stemper wrote:
>> Net net is that the only thing that ended up being common was the
>> __init__ methods. Two of the classes have identical __init__
>> methods; the third has a superset of that method. The other methods
>> all have completely different implementations. This isn't due to
>> poor coding, but due to the fact that what these model have
>> different physical characteristics.
>>
>> Not being that familiar with object-oriented programming (I grew up
>> on FORTRAN and c), I'm seeking opinions:
>>
>> Is there really any benefit to this change? Yes, I've eliminated
>> some (a few lines per class) duplicate code. On the other hand,
>> I've added the parent class and the (probably small, but not
>> non-existent) overhead of invoking super().
> 
> What you've done is the work you would have to do in a statically-typed
> language such as C++.  You've been taking advantage of duck typing

Upon review, it seems that I haven't. However, as noted in another
followup, I think that I've found a way to do so.

> Is it worth creating the superclass in Python?  It sounds like it's a
> bit marginal in your case.  I'm not that seasoned in object-oriented
> design either, but my yardstick would be how much common code does it
> eliminate?

About half a dozen lines. Here's the common part:

def __init__( self, xmlmodel, V, id ):

  try:
P_0s = xmlmodel.findall( 'RatedPower' )[0].text
self.P_0 = float( P_0s )
  except:
Utility.DataErr( "Power not specified for %s load" % (id) )
  if self.P_0<=0.0:
Utility.DataErr( "Power for %s load must be postive, not %s" \
  % (id,P_0s) )

Actually, looking over it, I see that I can slightly simplify this.
I suppose that's a good reason for putting it in one place -- if I
want to change it, I only need to do it once, not three times.

Thanks for your input.

-- 
Michael F. Stemper
Why doesn't anybody care about apathy?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Object-oriented philosophy

[Michael F. Stemper]

On 2018-09-06 10:40, Abdur-Rahmaan Janhangeer wrote:
> Also, get someone, preferrable a python engineer to review your code.

Sounds like an advertisement to me.

-- 
Michael F. Stemper
Why doesn't anybody care about apathy?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Object-oriented philosophy

[Michael F. Stemper]

On 2018-09-06 12:32, Stefan Ram wrote:
> "Michael F. Stemper"  writes:
>> Is there really any benefit to this change? Yes, I've eliminated
>> some (a few lines per class) duplicate code. On the other hand,
>> I've added the parent class and the (probably small, but not
>> non-existent) overhead of invoking super().
> 
>   You have a operation »Resistance( V )«.

Mathematically, that's an operation, I suppose. I tend to think of it
as either a function or a method.

>   OOP is advantageous if you can anticipate that you will want
>   to extend operations for other types.

Since the way that each operation (aside from __init__) differs
from one load type to the next, is there really an advantage?

>   I.e., if you anticipate a new type »ConstantVoltage«, you

Actually, although the possibility of other load models exists,
ConstantVoltage() would be impossible, since these models are
all defined based on the behavior of the load *in response to a
change in voltage*. But your point is well-taken, which is part
of why I considered doing inheritance.

>   can add an operation »Resistance( V )« for this new type
>   without changing the existing definitions (open-closed
>   principle).
> 
>   Non-OOP is advantageous if you can anticipate that you will
>   want to add new operations for the existing types.
> 
>   (Non-OOP means in this case that you have a single
>   definition of a function »Resistance( entity, V )« which
>   contains an internal multiple branch on the type of the
>   entity.)

To be honest, that sounds painful and hard to maintain. Of course,
back in my F77 days, it would have been the only option.

Thanks for your time.

-- 
Michael F. Stemper
Why doesn't anybody care about apathy?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: don't quite understand mailing list

[mm0fmf]

On 06/09/2018 21:06, Ethan Furman wrote:

On 09/06/2018 12:42 PM, Reto Brunner wrote:


What do you think the link, which is attached to every email you receive
from the list, is for? Listinfo sounds very promising, doesn't it?

And if you actually go to it you'll find:
"To unsubscribe from Python-list, get a password reminder, or change
your subscription options enter your subscription email address"

So how about you try that?


Reto,  your response is inappropriate.  If you can't be kind and/or
respectful, let someone else respond.

--
~Ethan~


Seriously if someone has a swanky signature advertising that they are a 
rocket scientist viz. "Software Contractor,  Missiles and Fire Control" 
and yet doesn't know what a language runtime is or how mailing lists 
work then they are asking for that kind of reply.


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

Re: don't quite understand mailing list

[Chris Angelico]

On Fri, Sep 7, 2018 at 6:44 AM, mm0fmf  wrote:
> On 06/09/2018 21:06, Ethan Furman wrote:
>>
>> On 09/06/2018 12:42 PM, Reto Brunner wrote:
>>
>>> What do you think the link, which is attached to every email you receive
>>> from the list, is for? Listinfo sounds very promising, doesn't it?
>>>
>>> And if you actually go to it you'll find:
>>> "To unsubscribe from Python-list, get a password reminder, or change
>>> your subscription options enter your subscription email address"
>>>
>>> So how about you try that?
>>
>>
>> Reto,  your response is inappropriate.  If you can't be kind and/or
>> respectful, let someone else respond.
>>
>
> Seriously if someone has a swanky signature advertising that they are a
> rocket scientist viz. "Software Contractor,  Missiles and Fire Control" and
> yet doesn't know what a language runtime is or how mailing lists work then
> they are asking for that kind of reply.
>

Fortunately, not everyone has to respond snarkily.

Richard, once you join a mailing list, ALL posts sent to it will come
to your inbox. But what you do with them after that is up to you. I
recommend configuring your mail client to filter the messages to their
own folder (or equivalent - if you're using Gmail, their own "tag"),
so you can then read them or ignore them at will, without them
cluttering up your main inbox.

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

Re: don't quite understand mailing list

[Ethan Furman]

On 09/06/2018 01:44 PM, mm0fmf wrote:


Seriously if someone has a swanky signature advertising that they are a rocket 
scientist viz. "Software Contractor,
Missiles and Fire Control" and yet doesn't know what a language runtime is or 
how mailing lists work then they are
asking for that kind of reply.


No, they are not asking for it, they are asking for help.

I chose not to reply because I didn't think I could do it kindly.  I also know I've asked totally bone-headed questions 
in the past (although they seemed legitimate when I was asking them).


In short, this list is not the place to be condescending nor mean-spirited.  If the urge strikes, pass it up and move to 
the next post.


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

Re: Object-oriented philosophy

[MRAB]

On 2018-09-06 21:24, Michael F. Stemper wrote:

On 2018-09-06 09:35, Rhodri James wrote:

On 06/09/18 15:04, Michael F. Stemper wrote:

Net net is that the only thing that ended up being common was the
__init__ methods. Two of the classes have identical __init__
methods; the third has a superset of that method. The other methods
all have completely different implementations. This isn't due to
poor coding, but due to the fact that what these model have
different physical characteristics.

Not being that familiar with object-oriented programming (I grew up
on FORTRAN and c), I'm seeking opinions:

Is there really any benefit to this change? Yes, I've eliminated
some (a few lines per class) duplicate code. On the other hand,
I've added the parent class and the (probably small, but not
non-existent) overhead of invoking super().


What you've done is the work you would have to do in a statically-typed
language such as C++.  You've been taking advantage of duck typing


Upon review, it seems that I haven't. However, as noted in another
followup, I think that I've found a way to do so.


Is it worth creating the superclass in Python?  It sounds like it's a
bit marginal in your case.  I'm not that seasoned in object-oriented
design either, but my yardstick would be how much common code does it
eliminate?


About half a dozen lines. Here's the common part:

def __init__( self, xmlmodel, V, id ):

   try:
 P_0s = xmlmodel.findall( 'RatedPower' )[0].text
 self.P_0 = float( P_0s )
   except:
 Utility.DataErr( "Power not specified for %s load" % (id) )
   if self.P_0<=0.0:
 Utility.DataErr( "Power for %s load must be postive, not %s" \
   % (id,P_0s) )

Actually, looking over it, I see that I can slightly simplify this.
I suppose that's a good reason for putting it in one place -- if I
want to change it, I only need to do it once, not three times.

Thanks for your input.

A word of advice: don't use a "bare" except, i.e. one that doesn't 
specify what exception(s) it should catch.


Your try...except above will catch _any_ exception. If you misspelled a 
name in the 'try' part, it would raise NameError, which would also be 
caught.


There are rare occasions when it's OK, but even then you'd just want to 
do something and then re-raise it.


Catch only those exceptions that you're prepared to deal with and allow 
any others to propagate and let you know that there's a problem!

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

Re: ModuleNotFoundError: No module named 'encodings'

[Thomas Jollans]

On 09/06/2018 09:46 PM, Jason Qian via Python-list wrote:

Hi

Need some help.

I have a C++ application that invokes Python.

...
Py_SetPythonHome("python_path");


This isn't actually a line in your code, is it? For one thing, 
Py_SetPythonHome expects a wchar_t*...



Py_Initialize();

This works fine on Python 3.6.4 version, but got errors on Python 3.7.0
when calling Py_Initialize(),

Fatal Python error: initfsencoding: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'


So, Python can't find a core module. This either means your Python 3.7 
build is broken, or it doesn't know where to look. Perhaps whatever it 
is you're actually passing to Py_SetPythonHome needs to be changed to 
point to the right place? (i.e. maybe you're giving it the location of 
the Python 3.6 library rather than the Python 3.7 one)


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

Re: don't quite understand mailing list

[Gene Heskett]

On Thursday 06 September 2018 16:44:20 mm0fmf wrote:

> On 06/09/2018 21:06, Ethan Furman wrote:
> > On 09/06/2018 12:42 PM, Reto Brunner wrote:
> >> What do you think the link, which is attached to every email you
> >> receive from the list, is for? Listinfo sounds very promising,
> >> doesn't it?
> >>
> >> And if you actually go to it you'll find:
> >> "To unsubscribe from Python-list, get a password reminder, or
> >> change your subscription options enter your subscription email
> >> address"
> >>
> >> So how about you try that?
> >
> > Reto,  your response is inappropriate.  If you can't be kind and/or
> > respectful, let someone else respond.
> >
> > --
> > ~Ethan~
>
> Seriously if someone has a swanky signature advertising that they are
> a rocket scientist viz. "Software Contractor,  Missiles and Fire
> Control" and yet doesn't know what a language runtime is or how
> mailing lists work then they are asking for that kind of reply.
>
> Just saying.
+1


-- 
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 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Debug script under pdb, how to avoid a bunch of errors caused by the exit()?

[Peter via Python-list]

I'm on 3.7.0 on Win 10, and get a different result. No traceback. 
Perhaps it's a bug in 3.4 that was fixed subsequently.


C:\test> py -m pdb bugInPDB.py
> c:\test\buginpdb.py(1)()
-> password = 'bad'
(Pdb) tbreak 3
Breakpoint 1 at c:\test\buginpdb.py:3
(Pdb) cont
Deleted breakpoint 1 at c:\test\buginpdb.py:3
> c:\test\buginpdb.py(3)()
-> print('bad password')
(Pdb) cont
bad password
The program exited via sys.exit(). Exit status: None
> c:\test\buginpdb.py(1)()
-> password = 'bad'
(Pdb) q

C:\test>

On 6/09/2018 7:38 PM, Jach Fong wrote:

Here the script file, test0.py:
--
password = 'bad'
if password == 'bad':
    print('bad password')
    exit()
else:
    print('good password')

print('something else to do')


    When running it under Python3.4 Windows Vista, no problem at all.

D:\Works\Python>py test0.py
bad password

    But if debug it under pdb:

D:\Works\Python>py -m pdb test0.py
> d:\works\python\test0.py(1)()
-> password = 'bad'
(Pdb) tbreak 3
Breakpoint 1 at d:\works\python\test0.py:3
(Pdb) cont
Deleted breakpoint 1 at d:\works\python\test0.py:3
> d:\works\python\test0.py(3)()
-> print('bad password')
(Pdb) cont
bad password
The program exited via sys.exit(). Exit status: None
> d:\works\python\test0.py(1)()
-> password = 'bad'
(Pdb) Traceback (most recent call last):
  File "C:\Python34\lib\pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "C:\Python34\lib\pdb.py", line 1542, in _runscript
    self.run(statement)
  File "C:\Python34\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "", line 1, in 
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "C:\Python34\lib\bdb.py", line 48, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Python34\lib\bdb.py", line 66, in dispatch_line
    self.user_line(frame)
  File "C:\Python34\lib\pdb.py", line 259, in user_line
    self.interaction(frame, None)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
ValueError: I/O operation on closed file.
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\python34\lib\cmd.py(126)cmdloop()
-> line = input(self.prompt)
(Pdb) Traceback (most recent call last):
  File "C:\Python34\lib\pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "C:\Python34\lib\pdb.py", line 1542, in _runscript
    self.run(statement)
  File "C:\Python34\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "", line 1, in 
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "C:\Python34\lib\bdb.py", line 48, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Python34\lib\bdb.py", line 66, in dispatch_line
    self.user_line(frame)
  File "C:\Python34\lib\pdb.py", line 259, in user_line
    self.interaction(frame, None)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
ValueError: I/O operation on closed file.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python34\lib\runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Python34\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Python34\lib\pdb.py", line 1688, in 
    pdb.main()
  File "C:\Python34\lib\pdb.py", line 1680, in main
    pdb.interaction(None, t)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
ValueError: I/O operation on closed file.

D:\Works\Python>

    How to get rid of these?

Best Regards,
Jach Fong


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus





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

Re: Cross platform mutex to prevent script running more than instance?

[eryk sun]

On Tue, Sep 4, 2018 at 5:47 PM, Cameron Simpson  wrote:
>
> The downside with mkdir, and also with pd files really, is that a program or
> OS abort can leave them lying around. Being persistent objects, some kind of
> cleanup is needed.

While the OP needs a cross-platform solution, if it's just Windows,
the cleanup problem for a temporary directory or lock file can be
handled via the delete-on-close flag. This includes the case in which
the process is forcefully terminated. However, it won't help if the
system itself crashes or gets powered off abruptly.

Details for a directory:

*NT API*
Call NtCreateFile with DELETE access, FILE_CREATE disposition, and the
options FILE_DIRECTORY_FILE | FILE_DELETE_ON_CLOSE.

*Windows API (undocumented)*
Call CreateFile with CREATE_NEW disposition and the attributes/flags
FILE_ATTRIBUTE_DIRECTORY | FILE_FLAG_POSIX_SEMANTICS |
FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_DELETE_ON_CLOSE.

*Windows API (documented)*
Call CreateDirectory and then CreateFile with OPEN_EXISTING
disposition and the flags FILE_FLAG_BACKUP_SEMANTICS |
FILE_FLAG_DELETE_ON_CLOSE.

*C/POSIX API (undocumented)*
Call os.mkdir and then os.open with the flags O_OBTAIN_DIR (0x2000)
and O_TEMPORARY. (O_OBTAIN_DIR requires the Universal CRT, which is
used by CPython 3.5+.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[sjatkins]

On Sunday, July 1, 2018 at 10:06:49 AM UTC-7, Abdur-Rahmaan Janhangeer wrote:
> was viewing pep526, so, finally, python cannot do without hinting the type
> as other languages?
> will python finally move to
> int x = 3 where int is a pre annotation?
> 
> i am not arguing it's usefulness but rather, does it fit with python?
> 
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ

Sigh.  I came to python to escape type declaration jails and the infinite hair 
splitting of type inference systems.  I am not at all happy to see this stuff 
in python code. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why emumerated list is empty on 2nd round of print?

[Steven D'Aprano]

On Thu, 06 Sep 2018 11:50:17 -0700, Viet Nguyen via Python-list wrote:

> If I do this "aList = enumerate(numList)", isn't it
> stored permanently in aList now?

Yes, but the question is "what is *it* that is stored? The answer is, it 
isn't a list, despite the name you choose. It is an enumerate iterator 
object, and iterator objects can only be iterated over once.

If you really, truly need a list, call the list constructor:

aList = list(enumerate(numList))

but that's generally a strange thing to do. It is more common to just 
call enumerate when you need it, not to hold on to the reference for 
later.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: PEP 526 - var annotations and the spirit of python

[Abdur-Rahmaan Janhangeer]

hey,

greetings, how did you come across this thread?


Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: don't quite understand mailing list

[Steven D'Aprano]

On Thu, 06 Sep 2018 13:06:22 -0700, Ethan Furman wrote:

> On 09/06/2018 12:42 PM, Reto Brunner wrote:
> 
>> What do you think the link, which is attached to every email you
>> receive from the list, is for? Listinfo sounds very promising, doesn't
>> it?
>>
>> And if you actually go to it you'll find: "To unsubscribe from
>> Python-list, get a password reminder, or change your subscription
>> options enter your subscription email address"
>>
>> So how about you try that?
> 
> Reto,  your response is inappropriate.  If you can't be kind and/or
> respectful, let someone else respond.

No it wasn't inappropriate, and your attack on Reto is uncalled for.

Reto's answer was kind and infinitely more respectful than your 
unnecessary criticism. As far as I can tell, this is Reto's first post 
here. After your hostile and unwelcoming response, I wouldn't be 
surprised if it was his last.

His answer was both helpful and an *amazingly* restrained and kind 
response to a stupid question[1] asked by somebody claiming to be an 
professional software engineer. It was not condescending or mean-
spirited, as you said in another post, nor was it snarky.

But even had the OP been a total beginner to computing, it was still a 
helpful response containing the information needed to solve their 
immediate problem (how to unsubscribe from the list) with just the 
*tiniest* (and appropriate) hint of reproach to encourage them to learn 
how to solve their own problems for themselves so that in future, they 
will be a better contributor to whatever discussion forums they might 
find themselves on.

Ethan, you are a great contributor on many of the Python mailing lists, 
but your tone-policing is inappropriate, and your CoC banning of Rick and 
Bart back in July was an excessive and uncalled for misuse of moderator 
power.

To my shame, I didn't say anything at the time, but I won't be 
intimidated any longer by fear of the CoC and accusations of incivility. 
I'm speaking up now because your reply to Reto is unwelcoming, unhelpful 
and disrespectful, and coming from a moderator who has been known to ban 
people, that makes it even more hostile.




[1] Yes, there are such things as stupid questions. If your doctor asked 
you "remind me again, which end of the needle goes into your arm?" what 
would you do?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Object-oriented philosophy

[Steven D'Aprano]

On Thu, 06 Sep 2018 22:00:26 +0100, MRAB wrote:

> On 2018-09-06 21:24, Michael F. Stemper wrote:
[...]
>>try:
>>  P_0s = xmlmodel.findall( 'RatedPower' )[0].text 
>>  self.P_0 = float( P_0s )
>>except:
[...]

> A word of advice: don't use a "bare" except, i.e. one that doesn't
> specify what exception(s) it should catch.

Excellent advice!

More here:

https://realpython.com/the-most-diabolical-python-antipattern/





-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Debug script under pdb, how to avoid a bunch of errors caused by the exit()?

[Jach Fong]

I tried the following tests under pdb,

1. WinPython 3.6.6 on Vista, still saw those errors.
2. Python 3.4 on Win7, still saw those errors.
3. Python 3.6.3 on Win7, it's fine, no errors.

Hmmm... seems both Python and OS are related?

--Jach

Peter via Python-list at 2018/9/7 AM 06:33 wrote:
I'm on 3.7.0 on Win 10, and get a different result. No traceback. 
Perhaps it's a bug in 3.4 that was fixed subsequently.


C:\test> py -m pdb bugInPDB.py
 > c:\test\buginpdb.py(1)()
-> password = 'bad'
(Pdb) tbreak 3
Breakpoint 1 at c:\test\buginpdb.py:3
(Pdb) cont
Deleted breakpoint 1 at c:\test\buginpdb.py:3
 > c:\test\buginpdb.py(3)()
-> print('bad password')
(Pdb) cont
bad password
The program exited via sys.exit(). Exit status: None
 > c:\test\buginpdb.py(1)()
-> password = 'bad'
(Pdb) q

C:\test>

On 6/09/2018 7:38 PM, Jach Fong wrote:

Here the script file, test0.py:
--
password = 'bad'
if password == 'bad':
    print('bad password')
    exit()
else:
    print('good password')

print('something else to do')


    When running it under Python3.4 Windows Vista, no problem at all.

D:\Works\Python>py test0.py
bad password

    But if debug it under pdb:

D:\Works\Python>py -m pdb test0.py
> d:\works\python\test0.py(1)()
-> password = 'bad'
(Pdb) tbreak 3
Breakpoint 1 at d:\works\python\test0.py:3
(Pdb) cont
Deleted breakpoint 1 at d:\works\python\test0.py:3
> d:\works\python\test0.py(3)()
-> print('bad password')
(Pdb) cont
bad password
The program exited via sys.exit(). Exit status: None
> d:\works\python\test0.py(1)()
-> password = 'bad'
(Pdb) Traceback (most recent call last):
  File "C:\Python34\lib\pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "C:\Python34\lib\pdb.py", line 1542, in _runscript
    self.run(statement)
  File "C:\Python34\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "", line 1, in 
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "C:\Python34\lib\bdb.py", line 48, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Python34\lib\bdb.py", line 66, in dispatch_line
    self.user_line(frame)
  File "C:\Python34\lib\pdb.py", line 259, in user_line
    self.interaction(frame, None)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
ValueError: I/O operation on closed file.
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\python34\lib\cmd.py(126)cmdloop()
-> line = input(self.prompt)
(Pdb) Traceback (most recent call last):
  File "C:\Python34\lib\pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "C:\Python34\lib\pdb.py", line 1542, in _runscript
    self.run(statement)
  File "C:\Python34\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "", line 1, in 
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "d:\works\python\test0.py", line 1, in 
    password = 'bad'
  File "C:\Python34\lib\bdb.py", line 48, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Python34\lib\bdb.py", line 66, in dispatch_line
    self.user_line(frame)
  File "C:\Python34\lib\pdb.py", line 259, in user_line
    self.interaction(frame, None)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
ValueError: I/O operation on closed file.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python34\lib\runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Python34\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Python34\lib\pdb.py", line 1688, in 
    pdb.main()
  File "C:\Python34\lib\pdb.py", line 1680, in main
    pdb.interaction(None, t)
  File "C:\Python34\lib\pdb.py", line 346, in interaction
    self._cmdloop()
  File "C:\Python34\lib\pdb.py", line 319, in _cmdloop
    self.cmdloop()
  File "C:\Python34\lib\cmd.py", line 126, in cmdloop
    line = input(self.prompt)
ValueError: I/O operation on closed file.

D:\Works\Python>

    How to get rid of these?

Best Regards,
Jach Fong


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus






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

Re: don't quite understand mailing list

[Marko Rauhamaa]

mm0fmf :
> On 06/09/2018 21:06, Ethan Furman wrote:
>> On 09/06/2018 12:42 PM, Reto Brunner wrote:
>>> What do you think the link, which is attached to every email you
>>> receive from the list, is for? Listinfo sounds very promising,
>>> doesn't it?
>>>
>>> And if you actually go to it you'll find: "To unsubscribe from
>>> Python-list, get a password reminder, or change your subscription
>>> options enter your subscription email address"
>>>
>>> So how about you try that?
>>
>> Reto,  your response is inappropriate.  If you can't be kind and/or
>> respectful, let someone else respond.
>
> Seriously if someone has a swanky signature advertising that they are
> a rocket scientist viz. "Software Contractor, Missiles and Fire
> Control" and yet doesn't know what a language runtime is or how
> mailing lists work then they are asking for that kind of reply.

I'm with Ethan on this one.

There was nothing in the original posting that merited ridicule.


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

Re: OpenSSL error

[dieter]

Peng Yu  writes:
> ...
> from OpenSSL import rand, crypto, SSL
>   File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/OpenSSL/SSL.py",
> line 118, in 
> SSL_ST_INIT = _lib.SSL_ST_INIT
> AttributeError: 'module' object has no attribute 'SSL_ST_INIT'

That is strange.

The "_lib" actually comes from "cryptography.hazmat.bindings._openssl".
Apparently, it defines quite some of the SSL related constants
but not "SSL_ST_INIT".

A potential reason could be that
a wrong version of the "cryptography" packages is used, maybe
due to a bad "PYTHONPATH" or "sys.path" value. Import "cryptography"
and look at its "__file__" to verify where is comes from.

Another potential reason: the contents of "_lib" might depend
on the openssl system library. Then an incompatible version
of this library might cause the problem.

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