Re: Python's method-resolution algorithm: An implementation question

[Evan Aad]

Thanks!

On Tue, Aug 15, 2017 at 10:41 PM, Ian Kelly  wrote:
>
> On Tue, Aug 15, 2017 at 12:57 PM, Evan Aad  wrote:
> > I don't see how, since the L(B*)'s are listed in order in the argument
> > list: L(B1), L(B2), ..., and each L(B*) starts with B*: L(B1) =  > ...>, L(B2) = , ...
> >
> > Could you please give a counter-example?
>
> Sure.
>
> merge(, )  ->  
>
> vs:
>
> merge(, , )  ->  TypeError
>
> Or in Python:
>
> >>> class A1: pass
> >>> class A2: pass
> >>> class B1(A1): pass
> >>> class B2(A2, B1): pass
> >>> class C(B1, B2): pass
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: Cannot create a consistent method resolution order (MRO)
> for bases B1, B2
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed new syntax

[Ben Finney]

Gregory Ewing  writes:

> The whole reason to write something as a comprehension is because you
> want to express it declaratively. You're saying "this is the list I
> want, I don't care how you compute it."

That's certainly a strong reason for my choosing comprehension
expressions: when I don't want to write a sequence of statements in a
loop, an expression communicates the intent (“this is one expression
with one output; think of it as one operation”).

> Likewise, the reader should be able to read it as "this is the list
> produced, and you *don't have to care* how it gets computed."

So I find the ‘while’ proposed addition to be counter to that purpose,
and describe it as confounding the ability of the reader to reason about
the expression.

> Introducing procedural elements such as "while" into a comprehension
> messes that up, because suddenly the reader *does* have to care about
> details of how it gets computed.

Thanks for stating it so well, Greg.

-- 
 \  “The good thing about science is that it's true whether or not |
  `\  you believe in it.” —Neil deGrasse Tyson, 2011-02-04 |
_o__)  |
Ben Finney

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

Re: Proposed new syntax

[Gregory Ewing]

Steve D'Aprano wrote:
I take issue with your statement that relying on order of evaluation is always 
"a very bad idea".


Perhaps what I should say is that relying on side effects in
an expression occurring in a particular order is a bad idea.
Boolean operators are a well-understood special case that
doesn't extend to other expression elements. If you saw

   x = foo(y) + bar(z)

you wouldn't immediately assume it relied critically on
foo being called before bar -- would you?


And especially now that print is a regular function instead of a
statement, it is incredibly useful to stick a print or two in the middle of an
expression for debugging.


That's fine as a temporary hack, but I would never use that
for something the program needs to do as part of its normal
operation.


# paraphrase, not an actual quote
"Comprehensions might actually have well-defined semantics in terms
of for-loops, just as they are documented to have, but we should
pretend that they don't because some really complicated expressions
with side-effects can be confusing or buggy."


That's pretty much it, except I would delete "really
complicated". Any reliance on side effects in an expression
is confusing and bug-prone, IMO.

The whole reason to write something as a comprehension is
because you want to express it declaratively. You're saying
"this is the list I want, I don't care how you compute it."

Likewise, the reader should be able to read it as "this is
the list produced, and you *don't have to care* how it
gets computed."

Introducing procedural elements such as "while" into a
comprehension messes that up, because suddenly the reader
*does* have to care about details of how it gets computed.

And those details can be tricky. We've already seen how a
subtle error can creep in when you get a "while" and an
"if" in the wrong order!

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

Re: numpy not working any more

[breamoreboy]

On Tuesday, August 15, 2017 at 8:13:19 PM UTC+1, Poul Riis wrote:
> Den tirsdag den 15. august 2017 kl. 19.19.15 UTC+2 skrev bream...@gmail.com:
> > On Tuesday, August 15, 2017 at 5:23:29 PM UTC+1, Poul Riis wrote:
> > > Den tirsdag den 15. august 2017 kl. 07.29.05 UTC+2 skrev dieter:
> > > > Poul Riis writes:
> > > > > ...
> > > > > For some time I have been using python 3.6.0 on a windows computer.
> > > > > Suddenly, my numpy does not work any more.
> > > > > This one-liner program:
> > > > > import numpy as np
> > > > > results in the long error message below.
> > > > > ...
> > > > > Traceback (most recent call last):
> > > > >   File 
> > > > > "C:\Users\pr\AppData\Local\Programs\Python\Python36\lib\site-packages\numpy\core\__init__.py",
> > > > >  line 16, in 
> > > > > from . import multiarray
> > > > > ImportError: DLL load failed: Den angivne procedure blev ikke fundet.
> > > > 
> > > > Apparently, the module "multiarry" is implemented in a separate
> > > > DLL (= "Dynamically Loaded Library") and loading this DLL failed.
> > > > 
> > > > There can be several reasons for such a failure, among others:
> > > > 
> > > >  * the DLL is missing
> > > > 
> > > >  * the DLL is corrupted
> > > > 
> > > >  * the DLL depends on something which is missing or corrupted
> > > > 
> > > >  * there is a version mismatch (e.g. between the DLL and the Python
> > > >trying to load it)
> > > > 
> > > > 
> > > > An initial step could be to try to reinstall "numpy" and
> > > > see whether the problem goes away.
> > > 
> > > I have reinstalled numpy several times - doesn't help.
> > 
> > The short answer is you need to upgrade Python, not numpy.
> > 
> > For the long answer please see 
> > https://stackoverflow.com/questions/44537131/numpy-library-importerror-dll-load-failed-the-specified-procedure-could-not-be
> >  which in turn refers to https://bugs.python.org/issue29943.
> > 
> > Kindest regards.
> > 
> > Mark Lawrence.
> 
> I mentioned in my original question that I have tried Python 3.6.2 and that 
> it indeed had no problems with numpy but that it on the other hand gave rize 
> to another problem, namely failing installation of vtk (pip says 'Couldn't 
> find a version that satisfies the requirement vtk'.
> 
> Poul Riis

Pip won't know anything about VTK, you have to download it yourself from 
http://www.vtk.org/.

Kindest regards.

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

Re: Python's method-resolution algorithm: An implementation question

[Ian Kelly]

On Tue, Aug 15, 2017 at 12:57 PM, Evan Aad  wrote:
> I don't see how, since the L(B*)'s are listed in order in the argument
> list: L(B1), L(B2), ..., and each L(B*) starts with B*: L(B1) =  ...>, L(B2) = , ...
>
> Could you please give a counter-example?

Sure.

merge(, )  ->  

vs:

merge(, , )  ->  TypeError

Or in Python:

>>> class A1: pass
>>> class A2: pass
>>> class B1(A1): pass
>>> class B2(A2, B1): pass
>>> class C(B1, B2): pass
Traceback (most recent call last):
  File "", line 1, in 
TypeError: Cannot create a consistent method resolution order (MRO)
for bases B1, B2
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A question on modification of a list via a function invocation

[Fred Stluka]

Here is my attempt to clarify the situation with some ascii graphics.
(Well, not ascii, but utf-8 box-drawing characters — I hope they come 
through ok.

And, of curse, it won't display properly with a proportional font.)

Here's a VERY useful tool for understanding/explaining/drawing
such code snippets:
- http://pythontutor.com

At the "Edit code" link, you can type/paste your own Python
statements and have the tool single-step though them.  At each
step, it draws the data structures with values, links to other data
structures, etc.  A great Python visualization tool!

Enjoy!
--Fred

Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.


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

Re: numpy not working any more

[Poul Riis]

Den tirsdag den 15. august 2017 kl. 19.19.15 UTC+2 skrev bream...@gmail.com:
> On Tuesday, August 15, 2017 at 5:23:29 PM UTC+1, Poul Riis wrote:
> > Den tirsdag den 15. august 2017 kl. 07.29.05 UTC+2 skrev dieter:
> > > Poul Riis writes:
> > > > ...
> > > > For some time I have been using python 3.6.0 on a windows computer.
> > > > Suddenly, my numpy does not work any more.
> > > > This one-liner program:
> > > > import numpy as np
> > > > results in the long error message below.
> > > > ...
> > > > Traceback (most recent call last):
> > > >   File 
> > > > "C:\Users\pr\AppData\Local\Programs\Python\Python36\lib\site-packages\numpy\core\__init__.py",
> > > >  line 16, in 
> > > > from . import multiarray
> > > > ImportError: DLL load failed: Den angivne procedure blev ikke fundet.
> > > 
> > > Apparently, the module "multiarry" is implemented in a separate
> > > DLL (= "Dynamically Loaded Library") and loading this DLL failed.
> > > 
> > > There can be several reasons for such a failure, among others:
> > > 
> > >  * the DLL is missing
> > > 
> > >  * the DLL is corrupted
> > > 
> > >  * the DLL depends on something which is missing or corrupted
> > > 
> > >  * there is a version mismatch (e.g. between the DLL and the Python
> > >trying to load it)
> > > 
> > > 
> > > An initial step could be to try to reinstall "numpy" and
> > > see whether the problem goes away.
> > 
> > I have reinstalled numpy several times - doesn't help.
> 
> The short answer is you need to upgrade Python, not numpy.
> 
> For the long answer please see 
> https://stackoverflow.com/questions/44537131/numpy-library-importerror-dll-load-failed-the-specified-procedure-could-not-be
>  which in turn refers to https://bugs.python.org/issue29943.
> 
> Kindest regards.
> 
> Mark Lawrence.

I mentioned in my original question that I have tried Python 3.6.2 and that it 
indeed had no problems with numpy but that it on the other hand gave rize to 
another problem, namely failing installation of vtk (pip says 'Couldn't find a 
version that satisfies the requirement vtk'.

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

Re: Python's method-resolution algorithm: An implementation question

[Evan Aad]

I don't see how, since the L(B*)'s are listed in order in the argument
list: L(B1), L(B2), ..., and each L(B*) starts with B*: L(B1) = , L(B2) = , ...

Could you please give a counter-example?

On Tue, Aug 15, 2017 at 9:44 PM, Ian Kelly  wrote:
>
> On Tue, Aug 15, 2017 at 9:56 AM, Evan Aad  wrote:
> > According to the description of Python's method resolution order (mro)
> > (https://www.python.org/download/releases/2.3/mro/), a.k.a. C3
> > linearization (see Wikipedia), the algorithm can be described as
> > follows:
> >
> > "the linearization of C is the sum of C plus the merge of the
> > linearizations of the parents and the list of the parents."
> >
> > Symbolically, the algorithm is defined recursively thus:
> >
> > L(O) = 
> > L(C) =  + merge(L(B1),..., L(Bn), )
> >
> > where
> >
> > * O is the class from which every class inherits.
> > * C is a class that inherits directly from B1, ..., Bn, in this order.
> > * < and > are list delimiters.
> > * + is the list-concatenation operator.
> > * 'merge' merges its list arguments into a single list with no
> > repetitions in the manner described in the next paragraph.
> >
> > Consider the head of the first list, i.e L(B1)[0]: if it is a good
> > head, i.e. if it is not in the proper tail of any of the other lists,
> > add it to the linearization of C, and remove it from all the lists in
> > the merge. Otherwise, consider the head of the next list, etc. Repeat
> > until no more classes, or no good heads. In the latter case, it is
> > impossible to construct the merge.
> >
> >
> >
> > Why is the list  of parents given as an argument to
> > 'merge'? Will the algorithm produce different results if this argument
> > is omitted?
>
> It ensures that the parents are linearized in that order. Without that
> list, it would be possible for B2 to appear before B1 in the MRO of C.
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A question on modification of a list via a function invocation

[Larry Hudson via Python-list]

On 08/14/2017 08:25 PM, Larry Hudson wrote:
[snip]


Here is my attempt to clarify the situation with some ascii graphics.
(Well, not ascii, but utf-8 box-drawing characters — I hope they come through 
ok.
And, of curse, it won't display properly with a proportional font.)

The left side is the program lines, and the right side tries to show the way Python implements 
the name binding to the data in memory.  (But I abbreviated the long assignment line,

alist[0],alist[1],alist[2]=3,6,9 to )

Program line  Variable bound to memory

===  Initial assignment  

ss = [1, 2, 3]  ss ───> [1, 2, 3]

===  test() code  ===

def test(alist):ss ─┬─> [1, 2, 3]
  alist ─┘
-
 alist = [3, 6, 9]   ss ───> [1, 2, 3]
  alist ───> [3, 6, 9]
-
 return  ss ───> [1, 2, 3]
  alist 

===  test1() code  ==
def test1(alist):   ss ─┬─> [1, 2, 3]
  alist ─┘
-
 ss ─┬─> [3, 6, 9]
  alist ─┘
-
 return  ss ───> [3, 6, 9]
  alist 

===  test2() code  ==
def test2(alist):   ss ─┬─> [1, 2, 3]
  alist ─┘
-
ss ─┬─> [3, 6, 9]
 alist ─┘
-
 alist = [30, 60, 90]ss ───> [3, 6, 9]
  alist ───> [30, 60, 90]
-
 return  ss ───> [3, 6, 9]
  alist 



This needs a minor clarification to the test1 example, plus I want to emphasize that the 
assignment here is through the alist variable.


===  test1() code  ==
def test1(alist):ss ─┬─> [1, 2, 3]
  alist ─┘
-
 ss ─┬─> [3, 6, 9]
  alist ─┘
-
 return  ss ───> [3, 6, 9]
  alist   There is nothing to garbage 
collect here.


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

Re: Python's method-resolution algorithm: An implementation question

[Ian Kelly]

On Tue, Aug 15, 2017 at 9:56 AM, Evan Aad  wrote:
> According to the description of Python's method resolution order (mro)
> (https://www.python.org/download/releases/2.3/mro/), a.k.a. C3
> linearization (see Wikipedia), the algorithm can be described as
> follows:
>
> "the linearization of C is the sum of C plus the merge of the
> linearizations of the parents and the list of the parents."
>
> Symbolically, the algorithm is defined recursively thus:
>
> L(O) = 
> L(C) =  + merge(L(B1),..., L(Bn), )
>
> where
>
> * O is the class from which every class inherits.
> * C is a class that inherits directly from B1, ..., Bn, in this order.
> * < and > are list delimiters.
> * + is the list-concatenation operator.
> * 'merge' merges its list arguments into a single list with no
> repetitions in the manner described in the next paragraph.
>
> Consider the head of the first list, i.e L(B1)[0]: if it is a good
> head, i.e. if it is not in the proper tail of any of the other lists,
> add it to the linearization of C, and remove it from all the lists in
> the merge. Otherwise, consider the head of the next list, etc. Repeat
> until no more classes, or no good heads. In the latter case, it is
> impossible to construct the merge.
>
>
>
> Why is the list  of parents given as an argument to
> 'merge'? Will the algorithm produce different results if this argument
> is omitted?

It ensures that the parents are linearized in that order. Without that
list, it would be possible for B2 to appear before B1 in the MRO of C.
-- 
https://mail.python.org/mailman/listinfo/python-list

PyDev 5.9.2 released

[Fabio Zadrozny]

PyDev 5.9.2 Release Highlights

   -

   *Important* PyDev now requires Java 8 and Eclipse 4.6 (Neon) onwards.
   - PyDev 5.2.0 is the last release supporting Eclipse 4.5 (Mars).
   -

   *Debugger*
   - Integrated speedups for Python 3.6 which use the new Python hook which
  allows the debugger to add breakpoints through bytecode manipulation.
  - Some critical fixes related to issues in the latest debugger
  (#PyDev-837, #PyDev-838, #PyDev-817).
   -

   Added support for having isort as the engine for import sorting.
   - Fixed issue on text search with *Lucene* when the user had another
   plugin which also used lucene (*#PyDev-826*).
   - From this version onwards, PyDev is built with a proper certificate
   (previous versions used a self-signed certificate).
   - Google App Engine templates now working out of the box (patch by *Mat
   Booth*).
   - Optimization in editor highlighting when dealing with huge files.
   - Some bugfixes in pytest integration.
   - *cv2* added to forced builtins by default for working with OpenCV.
   - Fixed issue when parsing empty f-string.

What is PyDev?

PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and
IronPython development.

It comes with goodies such as code completion, syntax highlighting, syntax
analysis, code analysis, refactor, debug, interactive console, etc.

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com
What is LiClipse?

LiClipse is a PyDev standalone with goodies such as support for Multiple
cursors, theming, TextMate bundles and a number of other languages such as
Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript,
etc.

It's also a commercial counterpart which helps supporting the development
of PyDev.

Details on LiClipse: http://www.liclipse.com/

Cheers,

--
Fabio Zadrozny
--

Software Developer

LiClipse
http://www.liclipse.com

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

PyVmMonitor - Python Profiler
http://www.pyvmmonitor.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed new syntax

[Steve D'Aprano]

On Tue, 15 Aug 2017 08:26 am, Gregory Ewing wrote:

> Ben Finney wrote:
>> That the comprehension
>> syntax *does not* necessarily connote a procedural loop, but instead can
>> quite reasonably be interpreted as its designer intended, a single
>> conceptual operation.
> 
> To put it another way: Consider that a comprehension is an
> expression, and I think most people would agree that relying
> on order of evaluation in an expression is a very bad idea,
> since it hurts readability and is prone to subtle bugs.

So you've stopped arguing that list comprehensions don't have a defined order
of evaluation, and are now arguing that code which relies on that order of
evaluation is hard to reason about? I suppose that's progress :-)

I take issue with your statement that relying on order of evaluation is always 
"a very bad idea". Order of evaluation in Python is well-defined, and we
frequently rely on it. There is nothing wrong with writing code like:

x = y + 1/z

x is not None and x > 1

a, b = b, a

while x in foo or x not in bar

and similar. And especially now that print is a regular function instead of a
statement, it is incredibly useful to stick a print or two in the middle of an
expression for debugging. You can't use that trick everywhere, but it is
especially useful in generator expressions as a way of seeing when its called
and yields a value:

(print('generator', x) or expression for x in something)

for example.

But really, the argument that you seem to be making:

# paraphrase, not an actual quote
"Comprehensions might actually have well-defined semantics in terms
of for-loops, just as they are documented to have, but we should
pretend that they don't because some really complicated expressions
with side-effects can be confusing or buggy."

seems pretty dubious to me.


As they say, "A man's got to know his limitations." If you program code that is
as complicated as you can understand, you won't be clever enough to debug it
when it goes wrong. That applies whether we're talking about order of
evaluation, basic arithmetic, threads, async programming, functional idioms,
levels of abstraction or spaghetti code. That makes a good argument for writing
conservative code that is the simplest thing that will work (for some
definition of "work").

It's not an argument for treating the semantics of code as different from what
those semantics actually are.



-- 
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: numpy not working any more

[breamoreboy]

On Tuesday, August 15, 2017 at 5:23:29 PM UTC+1, Poul Riis wrote:
> Den tirsdag den 15. august 2017 kl. 07.29.05 UTC+2 skrev dieter:
> > Poul Riis writes:
> > > ...
> > > For some time I have been using python 3.6.0 on a windows computer.
> > > Suddenly, my numpy does not work any more.
> > > This one-liner program:
> > > import numpy as np
> > > results in the long error message below.
> > > ...
> > > Traceback (most recent call last):
> > >   File 
> > > "C:\Users\pr\AppData\Local\Programs\Python\Python36\lib\site-packages\numpy\core\__init__.py",
> > >  line 16, in 
> > > from . import multiarray
> > > ImportError: DLL load failed: Den angivne procedure blev ikke fundet.
> > 
> > Apparently, the module "multiarry" is implemented in a separate
> > DLL (= "Dynamically Loaded Library") and loading this DLL failed.
> > 
> > There can be several reasons for such a failure, among others:
> > 
> >  * the DLL is missing
> > 
> >  * the DLL is corrupted
> > 
> >  * the DLL depends on something which is missing or corrupted
> > 
> >  * there is a version mismatch (e.g. between the DLL and the Python
> >trying to load it)
> > 
> > 
> > An initial step could be to try to reinstall "numpy" and
> > see whether the problem goes away.
> 
> I have reinstalled numpy several times - doesn't help.

The short answer is you need to upgrade Python, not numpy.

For the long answer please see 
https://stackoverflow.com/questions/44537131/numpy-library-importerror-dll-load-failed-the-specified-procedure-could-not-be
 which in turn refers to https://bugs.python.org/issue29943.

Kindest regards.

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

Python's method-resolution algorithm: An implementation question

[Evan Aad]

According to the description of Python's method resolution order (mro)
(https://www.python.org/download/releases/2.3/mro/), a.k.a. C3
linearization (see Wikipedia), the algorithm can be described as
follows:

"the linearization of C is the sum of C plus the merge of the
linearizations of the parents and the list of the parents."

Symbolically, the algorithm is defined recursively thus:

L(O) = 
L(C) =  + merge(L(B1),..., L(Bn), )

where

* O is the class from which every class inherits.
* C is a class that inherits directly from B1, ..., Bn, in this order.
* < and > are list delimiters.
* + is the list-concatenation operator.
* 'merge' merges its list arguments into a single list with no
repetitions in the manner described in the next paragraph.

Consider the head of the first list, i.e L(B1)[0]: if it is a good
head, i.e. if it is not in the proper tail of any of the other lists,
add it to the linearization of C, and remove it from all the lists in
the merge. Otherwise, consider the head of the next list, etc. Repeat
until no more classes, or no good heads. In the latter case, it is
impossible to construct the merge.



Why is the list  of parents given as an argument to
'merge'? Will the algorithm produce different results if this argument
is omitted?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: numpy not working any more

[Poul Riis]

Den tirsdag den 15. august 2017 kl. 07.29.05 UTC+2 skrev dieter:
> Poul Riis  writes:
> > ...
> > For some time I have been using python 3.6.0 on a windows computer.
> > Suddenly, my numpy does not work any more.
> > This one-liner program:
> > import numpy as np
> > results in the long error message below.
> > ...
> > Traceback (most recent call last):
> >   File 
> > "C:\Users\pr\AppData\Local\Programs\Python\Python36\lib\site-packages\numpy\core\__init__.py",
> >  line 16, in 
> > from . import multiarray
> > ImportError: DLL load failed: Den angivne procedure blev ikke fundet.
> 
> Apparently, the module "multiarry" is implemented in a separate
> DLL (= "Dynamically Loaded Library") and loading this DLL failed.
> 
> There can be several reasons for such a failure, among others:
> 
>  * the DLL is missing
> 
>  * the DLL is corrupted
> 
>  * the DLL depends on something which is missing or corrupted
> 
>  * there is a version mismatch (e.g. between the DLL and the Python
>trying to load it)
> 
> 
> An initial step could be to try to reinstall "numpy" and
> see whether the problem goes away.

I have reinstalled numpy several times - doesn't help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application Error

[Ian Kelly]

On Tue, Aug 15, 2017 at 3:37 AM, Alhassan Tom Alfa
 wrote:
> Dear Sir,
>
> I just downloaded Python on my PH Windows 10 PC but any time I tried to
> start the application it always give the following error message;
>
> Python.exe - Application Error
> The application was unable to start correctly (0xc07b). Click Ok to
> close the application.
>
> How this error be corrected? I really need to use this application

https://stackoverflow.com/questions/20650596/cannot-open-python-error-0xc07b
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Application Error

[Bob Gailer]

On Aug 15, 2017 9:50 AM, "Alhassan Tom Alfa"  wrote:
>
> Dear Sir,
>
> I just downloaded Python
Exactly what did you download?
Where did you download it from?
There are 32 bit versions and 64-bit versions. Did you download the one
corresponding to your computer?
Normally when you download python You are downloading an installer. Did you
run the installer?
on my PH
What is pH?
Windows 10 PC but any time I tried to
> start the application
When you say application are you referring to python or some Python program?
Exactly what are you doing to run the application? Be as specific as
possible.
it always give the following error message;
>
> Python.exe - Application Error
> The application was unable to start correctly (0xc07b). Click Ok to
> close the application.
Personally I have never heard of this error. Have you tried to Google it?
The comments above are my own comments they reflect my own experience there
may be others on this list who will give you a better answer.
>
> How this error be corrected? I really need to use this application
We are all volunteers who choose to help others with questions. Expressions
of urgency usually don't motivate us. So in the future just ask a question.
>
> Thank you in anticipation for a quick response
>
> Best Regards,
>
> Tom
>
> <
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
>
> Virus-free.
> www.avast.com
> <
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Application Error

[Alhassan Tom Alfa]

Dear Sir,

I just downloaded Python on my PH Windows 10 PC but any time I tried to
start the application it always give the following error message;

Python.exe - Application Error
The application was unable to start correctly (0xc07b). Click Ok to
close the application.

How this error be corrected? I really need to use this application

Thank you in anticipation for a quick response

Best Regards,

Tom


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-- 
https://mail.python.org/mailman/listinfo/python-list

Any advice on getting Pyscripter installed & working with Python on Windows 10 computer ?

[TKS]

>
>
> Hi there,
>
> I am trying to assist my daughter with a school IT task to install Python
> & Pyscripter on a Windows 10 notebook. (64 bit system)
>
> It seems no version of Pyscripter will work - it fails to complete the
> installation & ends with an error ("Python could not be properly
> initialised, we must quit").
> I have tried using 32 & 64 bit versions for both & alternating options,
> but same error comes up.
>
> Can you offer any suggestions on how to get this working ?
>
> Thank you.
> ​TK.
>


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

Re: Proposed new syntax

[Rustom Mody]

On Tuesday, August 15, 2017 at 5:48:43 PM UTC+5:30, Steve D'Aprano wrote:
> On Tue, 15 Aug 2017 02:54 pm, Rustom Mody wrote:
> 
> > On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
> [...]
> >> Suppose stdin contains "a\nb\nc\nd\ne\nf\ng\n".
> >> What is the meaning of
> >> [input(f"response{i}") for i in range(6)]?
> >> In Python, the predictable result is
> >> ['a', 'b', 'c', 'd', 'e', 'f']
> >> It would not be with some of Rustom Mody's 'equivalents'.
> 
> Indeed. Terry has hit the nail on the head here. Python's documented semantics
> is predictable and deterministic, and the documented semantics of
> comprehensions are explicitly based on sequential for-loops.
> 
> To continue to insist, in contradiction to the documentation, that list comps
> might legitimately operate in arbitrary order is simply irrational. If they
> behaved as Rustom is insisting they might, it would be a bug in the
> implementation.

I know that list-comps behave like the l2r-pass-doing-appends as SPECIFIED
in the docs.
In my view the IMPLEMENTATION is correct wrt that specification
Whereas the SPECIFICATION, in being over-specific is wrong

In the same way that if someone explaining C were to say that the '+' operator
is (the SAME AS) ADD x86 instructions and then proves that case by showing gcc 
-S's output.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed new syntax

[Steve D'Aprano]

On Tue, 15 Aug 2017 02:54 pm, Rustom Mody wrote:

> On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
[...]
>> Suppose stdin contains "a\nb\nc\nd\ne\nf\ng\n".
>> What is the meaning of
>> [input(f"response{i}") for i in range(6)]?
>> In Python, the predictable result is
>> ['a', 'b', 'c', 'd', 'e', 'f']
>> It would not be with some of Rustom Mody's 'equivalents'.

Indeed. Terry has hit the nail on the head here. Python's documented semantics
is predictable and deterministic, and the documented semantics of
comprehensions are explicitly based on sequential for-loops.

To continue to insist, in contradiction to the documentation, that list comps
might legitimately operate in arbitrary order is simply irrational. If they
behaved as Rustom is insisting they might, it would be a bug in the
implementation.


>> Or let L = .
>> This implementation of list reversal: [L.pop() for i in range(len(L))]
> 
> In languages, especially those with a clearly separated lang-spec from
> specific implementation-spec (eg C99), there is a sharp distinction made
> between - undefined behaviour
> - unspecified behaviour
> - erroneous behaviour
> 
> 
> Roughly:
> - Erroneous means compiler/runtime should flag an error
> - Undefined means implementation can format your hard disk and clear your bank
>   account

In *some* languages, not all, undefined means the implementation can format your
hard disk. Those languages include C (and perhaps C++). I don't know of any
other languages which are so hostile to the developer (and their end users) as
to specify such abominable behaviour and claim it is a feature. (There may be
others, I just don't know them.)

In general, undefined and unspecified are synonymous.


> 
https://stackoverflow.com/questions/18420753/unspecified-undefined-and-implementation-defined-behavior-wiki-for-c
> - Unspecified means not error but not spelled out
> 
> My point of suggesting those alternative implementations is precisely
> to make your examples above fall squarely into unspecified category

Terry's examples don't demonstrate unspecified behaviour. The order of execution
is completely specified. See the links to the docs I have already posted.


> Note that this would square with the informal practice seen in places like
> this ML/NG where a noob asks a question using a comprehension such as the
> ones you've used and someone more experienced pipes up "Dont do that"

Don't do that *in production code.*

[print(x, y) for x in values for y in others]

is a good way of learning how to read list comprehensions.

You're making the classic logical error of affirming the consequent:

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

we should avoid code with unspecified behaviour

we should avoid this code, therefore it must have unspecified behaviour

Just because code showing unspecified behaviour should be avoided, doesn't mean
that all code that should be avoided has unspecified behaviour.

There are plenty of reasons for avoiding certain misuses of comprehensions that
have nothing to do with unspecified behaviour.



-- 
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: Proposed new syntax

[Steve D'Aprano]

On Tue, 15 Aug 2017 01:26 pm, Paul Rubin wrote:

> Steve D'Aprano  writes:
[...]
>> In Haskell, you cannot get the last N elements of a list without
>> allocating memory for the previous ones.
> 
> lastn n xxs@(x:xs)
>   | length (take n xs) == n-1 = xxs
>   | otherwise = lastn n xs
> 
> main = print . lastn 5 $ [1..1000]
> 
> *Main> main
> [996,997,998,999,1000]
> 
> works for me. 

Right. Did you read the Stackoverflow page I linked to? They all pretty much say
the same thing, although most of the given solutions use `drop`. Sorry if my
wording was unclear.


-- 
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: Redirecting input of IDLE window

[Friedrich Rentsch]

On 08/14/2017 10:47 AM, Friedrich Rentsch wrote:

Hi,

I work interactively in an IDLE window most of the time and find 
"help (...)" very useful to summarize things. The display comes up 
directly (doesn't return a text, which I could edit, assign or store). 
I suspect that there are ways to redirect the display, say to a file. 
Thanks for suggestions.



Frederic




Peter Otten's "mypager" works well. All suggestions provide a welcome 
opportunity to learn more about the inner workings. Thank you all for 
your responses.


Frederic



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

Re: Solution Manual Test Bank for South-Western Federal Taxation 2018: Corporations, Partnerships, Estates and Trusts, 41st Edition by Hoffman

[alister via Python-list]

On Mon, 14 Aug 2017 15:48:02 -0700, zhilongch64 wrote:


Please do the whole world a big favour & NEVER reply to spam
if no-one responded this heinous practice would die.




-- 
 I hate users
 you sound like a sysadmin already!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed new syntax

[Gregory Ewing]

Paul Rubin wrote:

Historically (in "naive set theory") we didn't bother with any of this.
We could write { S : S \not\in S } for the set of all sets that are not
members of themselves.  Is S a member of itself ("Russell's paradox")?
Either way leads to contradiction.  So the comprehension axiom schemas
for set theory had to be designed to not allow formulas like that.


Personally I think mathematicians worry overly much about that.
What it means is that not every predicate can be used to define
a set. A manifestation of the same thing in computing is that
not every program you can write down will terminate. But we
don't warp our languages in an effort to make non-terminating
programs impossible; we just accept them as a fact of life
and move on.

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