Re: type lookuperror

[Peter Otten]

meInvent bbird wrote:

> when try keystone_client.tenants.get
> got error,
> 
> isn't this method for all kinds of function?
> 
 m = "4c9a0da00b904422a23341e35be7f8d7"
 ten = checkexception(keystone_client.tenants.get,
 tenant_id=checkexception(m.encode,encoding='ascii',errors='ignore'))
> Unexpected error: 
> None

That's because your and Chris' version of checkexception() have no explicit 
return statement and thus always return None. There doesn't seeem to be a 
tenant_id=None...

> On Thursday, August 18, 2016 at 10:22:43 AM UTC+8, Chris Angelico wrote:
>> On Thu, Aug 18, 2016 at 12:13 PM, meInvent bbird 
>> wrote:
>> > would like to check errors for every function i run,
>> > got error type lookuperror
>> >
>> > def checkexception(func, **kwargs):
>> > try:
>> > result = func(*tuple(value for _, value in kwargs.iteritems()))
>> > except:
>> > print "Unexpected error:", sys.exc_info()[0]
>> > try:
>> > print(func.__doc__)
>> > except:
>> > print("no doc error")
>> >
>> 
>> I'm going to be brutally honest, and simply say that this is terrible
>> code. I'm not even going to _try_ to fix it. Instead, here's a
>> completely rewritten form:
>> 
>> def checkexception(func, *args, **kwargs):
>> try:
>> result = func(*args, **kwargs)
>> except BaseException as e:
>> print("Exception raised: %s" % e)
>> try: print(func.__doc__)
>> except AttributeError: pass
>> raise # Let the exception keep happening.
>> 
>> But really, there are even better ways to do this. Just let the
>> exception happen, and then use something like ipython to help you
>> analyze the traceback.
>> 
>> ChrisA


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

Re: type lookuperror

[Chris Angelico]

On Thu, Aug 18, 2016 at 5:14 PM, Peter Otten <__pete...@web.de> wrote:
> meInvent bbird wrote:
>
>> when try keystone_client.tenants.get
>> got error,
>>
>> isn't this method for all kinds of function?
>>
> m = "4c9a0da00b904422a23341e35be7f8d7"
> ten = checkexception(keystone_client.tenants.get,
> tenant_id=checkexception(m.encode,encoding='ascii',errors='ignore'))
>> Unexpected error: 
>> None
>
> That's because your and Chris' version of checkexception() have no explicit
> return statement and thus always return None. There doesn't seeem to be a
> tenant_id=None...

Hmm. Yes, that's another bug I should have fixed as I was rewriting.
"return result" at the end.

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

Re: I am new to python. I have a few questions coming from an armature!

[Jussi Piitulainen]

Terry Reedy writes:
> On 8/17/2016 2:39 AM, Steven D'Aprano wrote:

[- -]

>> Because the C syntax is horrifically ugly, whereas the Python syntax
>> is very close to real English syntax.
>>
>> "What will you do tonight?"
>>
>> "Go to the movies, if I finish work on time, otherwise just go home."
>
> "If I finish work on on time, go to the movies, otherwise just go
> home."  is also real English syntax, and to me, more graceful.  It is
> certainly more neutral among the alternatives.  The inverted version
> implies a clear preference for the first alternative.

Conditional expressions should be compared to a more marginal English
construction where the two branches are noun phrases, or adverbial
phrases, or any other such phrases that are not statements or clauses.
Because, as expressions, conditional expressions stand for the value,
and any other intended effect should be considered an abuse of the
notation.

"Movies, if I finish on time, otherwise just home."
"If I finish on time, to the movies, otherwise just home."

"Coffee, if it's available, else spam."
"If there's coffee, then coffee, else spam."
"If there's coffee, then that, else if there's spam, then spam."

"One or more, unless the codomain is empty." # no else branch

I'm sure my ear is not reliable here, and I don't quite trust anybody's
made-up examples, and I would want to see naturally occurring examples
in their natural habitat, so ...

> It would be an interesting exercise to see which order for ternary
> expressions is more common in some large corpus of English text.

... yes. That's bound to be subtle and varied, and not at all conclusive
for a formal-language syntax, but definitely interesting. Perhaps even
better would be a grammarian's account of such observations. I'll see if
that copy of Huddleston and Pullum is still in our mail room.

But please consider calling them conditional expressions. Even K & R do.

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

Re: type lookuperror

[Peter Otten]

meInvent bbird wrote:

> would like to check errors for every function i run,
> got error type lookuperror
> 
> def checkexception(func, **kwargs):
> try:
> result = func(*tuple(value for _, value in kwargs.iteritems()))

You are turning keyword arguments into positional arguments. The order of 
entries in a dict is undefined and may even vary between runs of python:

$ PYTHONHASHSEED=random python -c 'print dict(foo=1, bar=2, baz=3).items()'
[('baz', 3), ('foo', 1), ('bar', 2)]
$ PYTHONHASHSEED=random python -c 'print dict(foo=1, bar=2, baz=3).items()'
[('baz', 3), ('foo', 1), ('bar', 2)]
$ PYTHONHASHSEED=random python -c 'print dict(foo=1, bar=2, baz=3).items()'
[('baz', 3), ('bar', 2), ('foo', 1)]
$ PYTHONHASHSEED=random python -c 'print dict(foo=1, bar=2, baz=3).items()'
[('foo', 1), ('baz', 3), ('bar', 2)]

If you want to turn keyword arguments into positional arguments you have to 
think about a mechanism to ensure the intended order.

> except:
> print "Unexpected error:", sys.exc_info()[0]
> try:
> print(func.__doc__)
> except:
> print("no doc error")


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

Re: What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Thursday 18 August 2016 03:29, Michael Selik wrote:

>> You might find this https://glyph.twistedmatrix.com/2016/08/attrs.html an
>> interesting read.
>>
> 
> I disagree with a few points from that blog post.
> 
> 1. I don't mind typing so much. I like to be explicit. The attrs library
> uses some overly-concise abbreviations. For example, what's the meaning of
> ``@attrs.s`` or ``attrs.ib``?

They're puns. Literally.

`attr.s` for "attrs", and `attr.ib` for "attrib(ute)".


There are longer, non-punny synonyms for these, but I don't remember what they 
are.


> 2. When inheriting from a namedtuple, I use the same class name for the
> base and the child, so my reprs look good.

Still, I think it is unfortunate that namedtuple does the wrong thing. Having 
to use the same name for the parent and child class could, potentially, make 
debugging more annoying.


> 3. I don't bother to fieldnames.split() when passing fieldnames as a
> space-separated string, because the split is unnecessary.

Because namedtuple does the split for you.


> 4. I *like* that namedtuple is backwards-compatible with tuples, so that
> refactoring from tuples to namedtuples is easy.

Correct. An "attrs" object is not a tuple.


> 5. Inheritance is useful. Sure, there are times it fails, but that's true
> for any technique.




-- 
Steve

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

Re: type lookuperror

[meInvent bbird]

if i use 

result = ""
before try
and return result at the end

as return of function can be any type

there will be type mismatch 

how to return the result of func ?

On Thursday, August 18, 2016 at 3:18:31 PM UTC+8, Chris Angelico wrote:
> On Thu, Aug 18, 2016 at 5:14 PM, Peter Otten <__pete...@web.de> wrote:
> > meInvent bbird wrote:
> >
> >> when try keystone_client.tenants.get
> >> got error,
> >>
> >> isn't this method for all kinds of function?
> >>
> > m = "4c9a0da00b904422a23341e35be7f8d7"
> > ten = checkexception(keystone_client.tenants.get,
> > tenant_id=checkexception(m.encode,encoding='ascii',errors='ignore'))
> >> Unexpected error: 
> >> None
> >
> > That's because your and Chris' version of checkexception() have no explicit
> > return statement and thus always return None. There doesn't seeem to be a
> > tenant_id=None...
> 
> Hmm. Yes, that's another bug I should have fixed as I was rewriting.
> "return result" at the end.
> 
> ChrisA

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

Re: type lookuperror

[Chris Angelico]

On Thu, Aug 18, 2016 at 5:44 PM, meInvent bbird  wrote:
> if i use
>
> result = ""
> before try
> and return result at the end
>
> as return of function can be any type
>
> there will be type mismatch
>
> how to return the result of func ?

If it raises an exception, it *does not have* a return value. That's
why I let the exception continue to bubble. But fundamentally, you
can't just carry on regardless. I recommend a complete rethink of what
you're trying to do here.

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

Re: I am new to python. I have a few questions coming from an armature!

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 7:22:50 PM UTC+12, Jussi Piitulainen wrote:
> But please consider calling them conditional expressions.

And don’t forget switch-expressions, or case-expressions, as some other 
advanced languages have had. Which my article showed how to do in Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Jussi Piitulainen]

Lawrence D’Oliveiro writes:

> On Thursday, August 18, 2016 at 7:22:50 PM UTC+12, Jussi Piitulainen wrote:
>> But please consider calling them conditional expressions.
>
> And don’t forget switch-expressions, or case-expressions, as some
> other advanced languages have had. Which my article showed how to do
> in Python.

Some such constructs in some languages are statements only.

If they are expressions, I'm happy to see their kind identified by the
keyword, as you do here. The one in Python would naturally be an
if-expression.

That looks a bit funny if the "keyword" does not look like a word, but
then programming languages do look funny, so why not:

   (c ? t : e)  # ?-expression

   (c -> t, e)  # ->-expression
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A strange list concatenation result

[Mok-Kong Shen]

Am 14.08.2016 um 13:06 schrieb ast:
[snip]

Thanks. The use of id() is very helpful in clarifying
what acutally happens in the present case.

M. K. Shen
--
https://mail.python.org/mailman/listinfo/python-list

Re: --> Running shell script with python

[Lawrence D’Oliveiro]

On Thursday, August 18, 2016 at 8:00:51 PM UTC+12, gm wrote:

> os.system("python /home/pi/test/testserver.sh") command
> 
> How to run shell ( not python ) script, from python code ?

Take out the “python” from the command.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Marko Rauhamaa]

Jussi Piitulainen :

> That looks a bit funny if the "keyword" does not look like a word, but
> then programming languages do look funny, so why not:
>
>(c ? t : e)  # ?-expression
>
>(c -> t, e)  # ->-expression

That ship has already sailed.


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

Re: I am new to python. I have a few questions coming from an armature!

[Steven D'Aprano]

On Thursday 18 August 2016 06:25, Terry Reedy wrote:

> On 8/17/2016 2:07 AM, Steven D'Aprano wrote:
> 
>> I realise that there are occasions where we might deliberate choose to
>> assign an intermediate value to its own variable, but all else being equal,
>> which would you prefer?
>>
>> #A
>> alist = []
>> alist.append(2)
>> alist.append(4)
>> alist.append(8)
>> process(alist)
[... snip additional examples ...]

> Up to here, #A is a useless and stupid.  Have you seen such code written?

As a matter of fact, yes.

Just the other day I posted an example from a former work-mate that was *worse* 
than any of those, something like this:

x = []
x.append(1)
x = len(x)



>> #A
>> def callback(btn):
>> return btn.do_the_thing(42) or default
>> the_button.setcommand(callback)
>> process(the_button)
>>
>> #B
>> the_button.setcommand(lambda btn: btn.do_the_thing(42) or default)
>> process(the_button)
> 
> This example is *not* parallel to the other 3.  Here, A is useful real
> code and might be preferred for multiple reasons.

Sure -- I acknowledged at the beginning that there may be reasons why you want 
to give an intermediate value its own variable name.


>> If you find yourself preferring B, B, B, A, you might ask yourself what
>> makes a function different that you prefer to keep temporary functions
>> around where they're not needed.
> 
> When 'callback' is set as the command of the button, it is not
> temporary, but must remain as long as the button remains.  Only the name
> binding is (possibly) disposable.

The name binding is certainly disposable, because if it wasn't, you couldn't 
use an anonymous function (a lambda). *In general*, keeping an additional named 
reference to the callback around is unnecessary and wasteful -- although, as 
you point out and as I acknowledged, there may be exceptions.


> Beginners often do not understand that the body of a lambda expression
> is evaluated in a new local namespace, and only when the resulting
> function is called, the same as with a def statement.  They then neglect
> to capture current values when writing lambda expressions in a for loop.

Sure. But since the behaviour of def functions and lambda functions are 
identical, writing a named def won't solve that problem.


>  for section_name, line_number in text.parser.toc:
>  def goto(line=line_number):
>  text.yview(line)
>  drop.add_command(label=section_name, command=goto)
> 
> To me, this is much better and I intend to commit it.  Thank you for
> prodding me to think through how bad the lambda form can be and to
> rewrite the loop so I don't cringe reading it.

The use of a named function here adds next to nothing. Instead of some number 
of anonymous functions called "", you have an equal number of functions 
all named "goto". There's no easy way to distinguish them, and likely no real 
need to distinguish them -- they are simple enough that you can be almost 
certain that they are correct just from reading the code. So I don't see any 
benefit over this:

 for section_name, line_number in text.parser.toc:
 drop.add_command(label=section_name, command=lambda
  line=line_number: text.yview(line))

except that it is easier to fit in 79 columns :-)


-- 
Steve

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

Re: I am new to python. I have a few questions coming from an armature!

[Jussi Piitulainen]

Marko Rauhamaa writes:

> Jussi Piitulainen wrote:
>
>> That looks a bit funny if the "keyword" does not look like a word,
>> but then programming languages do look funny, so why not:
>>
>>(c ? t : e)  # ?-expression
>>
>>(c -> t, e)  # ->-expression
>
> That ship has already sailed.

Sorry, what?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[meInvent bbird]

actually i would like to remove try except code in all function

and i feel that try except code for a large block code can not 
show which function name , which line number error,
if use try except for specified code block to show where it has error
it will have many ugly try except code and need many human force
to craft the code, i hope that code write once for program to program itself 
in future.

actually this method i ask is not good enough since it will need 
to add many function wrapper.

On Thursday, August 18, 2016 at 3:49:04 PM UTC+8, Chris Angelico wrote:
> On Thu, Aug 18, 2016 at 5:44 PM, meInvent bbird  wrote:
> > if i use
> >
> > result = ""
> > before try
> > and return result at the end
> >
> > as return of function can be any type
> >
> > there will be type mismatch
> >
> > how to return the result of func ?
> 
> If it raises an exception, it *does not have* a return value. That's
> why I let the exception continue to bubble. But fundamentally, you
> can't just carry on regardless. I recommend a complete rethink of what
> you're trying to do here.
> 
> ChrisA

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

Re: --> Running shell script with python

[gm]

On 08/18/2016 11:16 AM, Lawrence D’Oliveiro wrote:

On Thursday, August 18, 2016 at 8:00:51 PM UTC+12, gm wrote:


os.system("python /home/pi/test/testserver.sh") command

How to run shell ( not python ) script, from python code ?


Take out the “python” from the command.


:-) Damn :-). Thank you !

Tell me, do you know how can i send CTRl+C command from python to 
terminate this external shell script ?


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

Re: I am new to python. I have a few questions coming from an armature!

[Peter Otten]

Steven D'Aprano wrote:

> On Thursday 18 August 2016 06:25, Terry Reedy wrote:

> Sure. But since the behaviour of def functions and lambda functions are
> identical, writing a named def won't solve that problem.
> 
> 
>>  for section_name, line_number in text.parser.toc:
>>  def goto(line=line_number):
>>  text.yview(line)
>>  drop.add_command(label=section_name, command=goto)
>> 
>> To me, this is much better and I intend to commit it.  Thank you for
>> prodding me to think through how bad the lambda form can be and to
>> rewrite the loop so I don't cringe reading it.
> 
> The use of a named function here adds next to nothing. Instead of some
> number of anonymous functions called "", you have an equal number
> of functions all named "goto". 

There may be other lambdas that do something completely different. For 
someone not familiar with the code in question a name gives a good hint were 
to look.

> There's no easy way to distinguish them,
> and likely no real need to distinguish them -- they are simple enough that
> you can be almost certain that they are correct just from reading the
> code. So I don't see any benefit over this:
> 
>  for section_name, line_number in text.parser.toc:
>  drop.add_command(label=section_name, command=lambda
>   line=line_number: text.yview(line))
> 
> except that it is easier to fit in 79 columns :-)

There is also

>>> functools.partial(text.yview, line_number)
functools.partial(>, 42)

The repr() is unwieldy, but the underlying function and its arguments are 
there.

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

Re: --> Running shell script with python

[Lutz Horn]

Tell me, do you know how can i send CTRl+C command from python to
terminate this external shell script ?


os.system[1] is not an asynchronous function. It returns as soon as the 
called command terminates, not earlier.


If you want to execute a command in a subprocess, use 
subprocess.Popen[2]. You can then later kill this process using 
Popen.kill()[3].


>>> import subprocess
>>> p = suprocess.Popen(["sleep", "10]) # sleep 10 seconds
>>> p.kill()

Lutz

[1] https://docs.python.org/3/library/os.html#os.system
[2] https://docs.python.org/3/library/subprocess.html#subprocess.Popen
[3] https://docs.python.org/3/library/subprocess.html#subprocess.Popen.kill
--
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[Chris Angelico]

On Thu, Aug 18, 2016 at 7:55 PM, meInvent bbird  wrote:
> actually i would like to remove try except code in all function
>
> and i feel that try except code for a large block code can not
> show which function name , which line number error,
> if use try except for specified code block to show where it has error
> it will have many ugly try except code and need many human force
> to craft the code, i hope that code write once for program to program itself
> in future.
>
> actually this method i ask is not good enough since it will need
> to add many function wrapper.

You can't get a program to program itself. That's called the
Singularity [1], and depending on your point of view, it's either
still in the future, or fundamentally impossible. In any case,
computers today cannot program themselves.

So what exactly is it you're wanting? When an exception happens, the
entire traceback is recorded, and unless you're throwing that away,
it'll be shown to you. Just let the exception bubble all the way up to
top level, and then read the traceback. Some IDEs can even help you
step through the code to see context for each line of traceback;
ipython is also pretty helpful with reading tracebacks. I advise
getting to know the tools you have available, rather than trying to
reinvent the wheel.

ChrisA

[1] https://en.wikipedia.org/wiki/Technological_singularity
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Chris Angelico]

On Thu, Aug 18, 2016 at 7:32 PM, Steven D'Aprano
 wrote:
> So I don't see any
> benefit over this:
>
>  for section_name, line_number in text.parser.toc:
>  drop.add_command(label=section_name, command=lambda
>   line=line_number: text.yview(line))
>
> except that it is easier to fit in 79 columns :-)

Which is a VERY important benefit when you realize what's just
happened to your code. Wrapping after "command=lambda" and before
"line=linenumber" majorly obscures what's going on here. Here's a
better way to wrap that:

 for section_name, line_number in text.parser.toc:
 drop.add_command(label=section_name,
command=lambda line=line_number: text.yview(line))

However, this isn't an indictment of lambda, just proof that anyone
can misalign stuff by mistake.

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

Error in while loop code for packing items

[GP]

I have a list dictionary of items:
ListDictItem = [ {'Item No': 1,'Weight':610,'Quantity':2},{'Item No': 
2,'Weight':610,'Quantity':2},{'Item No': 3,'Weight':500,'Quantity':2},{'Item 
No': 4,'Weight':484,'Quantity':2},{'Item No': 
5,'Weight':470,'Quantity':2},{'Item No': 6,'Weight':440,'Quantity':2},{'Item 
No': 7,'Weight':440,'Quantity':2},{'Item No': 8,'Weight':400,'Quantity':2}]

I would like to pack the items in shelves such that the total weight of each 
shelf is less than a particular value. 

I have created a list of weights from above like this:
ItemWeigths: [610.0, 610.0, 500.0, 484.0, 470.0, 440.0,440, 400.0]


and a code which creates the first shelf :

shelves=[]
ShelvesWeightTotal = sum(shelves)
shelf=[]
new=[]
ShelfToPack=[]


for i in range(0,len(ItemWeigths)):
while ShelvesWeightTotal <=WeightOfObject:
  shelf += [ItemWeigths[i]]
  ShelvesWeightTotal = sum(shelf)

for k in range(0,len(shelf)):
  q1=ListDictItem[k]
  q2 = ListDictItem.pop(k) #deletes the items that are packed.
  shelves.append(q1)
  new.append(q2)   

ShelfToPack.append(shelves)

This code works but when I try to create other shelves, I made a while 
statement over the items that are remaining ,(while ItemsRemaining !=0) and I 
get an error for the code. The details are below:

Code:

while ListDictItem != []:

   for i in range(0,len(ItemsToCutLength)):
   while ShelvesLengthTotal <=LengthOfObject:
  shelves += [ItemWeigths[i]]
  ShelvesLengthTotal = sum(shelves)

   for k in range(0,len(shelves)):
  q1=ItemsToCut[k]
  q2 = ListDictItemt.pop(k) #deletes the items that are packed.
  shelf.append(q1)
  new.append(q2)   
   ListDictItem==ListDictItem 
ShelfToPack.append(shelf)


Error message:Traceback (most recent call last):
  File "C:\Project\Python\ReadExcel-xlrd.py", line 201, in 
q1=ListDictItem[k]
IndexError: list index out of range.


I would like the ShelfToPack list look like :

[[{'Item No': 1,'Weight':610,'Quantity':2},{'Item No': 
2,'Weight':610,'Quantity':2},{'Item No': 3,'Weight':500,'Quantity':2},{'Item 
No': 4,'Weight':484,'Quantity':2}],[{..},...{..}],[{..},...{..}]]

Any suggestion in pointing the error or to improve the code will be appreciated.

Thanks in advance!! 

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

Re: Error in while loop code for packing items

[Peter Otten]

GP wrote:

The error and your second snippet aren't compatible, so I assume the 
exception is raised by

> for k in range(0,len(shelf)):
>   q1=ListDictItem[k]
>   q2 = ListDictItem.pop(k) #deletes the items that are packed.

> Error message:Traceback (most recent call last):
>   File "C:\Project\Python\ReadExcel-xlrd.py", line 201, in 
> q1=ListDictItem[k]
> IndexError: list index out of range.

Take a moment to understand what happens if you iterate over the loop index 
like above:

items = ["foo", "bar", "baz"]

for k in range(len(items)):
item = items[k]
print(item)
items.pop(k)

You start with k=0, item is set to items[0], i. e. "foo", that is printed 
and then items.pop(0) removes "foo" from the list which now looks like

items = ["bar", "baz"]

Now k=1, item is set to items[1], ie. "baz" ("bar" is never processed), 
"baz" is printed and then items.pop(1) removes "baz" and the list becomes

items = ["bar"]

Now k=2, so when you access items[2] from a list with only one item you get 
the IndexError. To make similar code work you need a while loop:

while items:
item = items.pop(0)
print(item)

However, when you really want to remove all items you instead assign a new 
empty list

for item in items:
print(item)
items = []



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

PyDev 5.2.0 Released

[Fabio Zadrozny]

Release Highlights:
---

* **Important** PyDev now requires Java 8 and Eclipse 4.5 onwards.

* PyDev 4.5.5 is the last release supporting Java 7 and Eclipse 3.8.
* See: `update sites page`_ for the update site of older versions of
PyDev.
* See: the **PyDev does not appear after install** section on `the
download page`_ for help on using a Java 8 vm in Eclipse.

* Inital support for code-completion using **PEP 484 static type
declarations**.

* **Debugger**

* Fixed racing condition where the variables view would not be properly
shown in the debugger -- which made an additional select of the stack
required in order to show the variables (#PyDev-672).
* Reusing the existing stack from the thread in the debugger (so that
the expanded state of the variables is properly kept on step over).
* Fixed issue changing attribute of local variable in the variables
view (#PyDev.Debugger-56).
* Fixed issue on attach to process: it required the pydevd_tracing to
be at the top-level and it was moved to _pydevd_bundle (restored it to be a
public API).

* **Indentation**

* The default indent mode now changed to better follow PEP 8 guidelines:

* Indenting directly after {, [, ( will add one indent level.
* Indenting after another token in a line with a {, [, ( will
indent to the {, [, ( level.

* It's possible to restore previous indent modes (which either always
indented to the parenthesis level or always indented a single level) in the
preferences > PyDev > Editor > Typing.

* **Interactive console**

* IPython 5 now supported in interactive console (#PyDev-710).
* Fixed issue executing single line with multiple statements in console.
* Fixed issue executing a multiple line statement in Jython.

* **Others**

* The (fast) parser which detects the outline of a Python module now
handles mixed indentation (and additional fixes which could result in log
entries such as "Did not expect to find item below node: Assign...").
* Support for unpacking generalizations (PEP 448) which could still
result in a syntax error for the Python 3 grammar (#PyDev-701).
* Fixed error in code analysis when the code is connected to an RTC
source control (#PyDev-184, patch by Wesley Barroso Lopes)

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: I am new to python. I have a few questions coming from an armature!

[Marko Rauhamaa]

Chris Angelico :
> Folks, read the whole thread before posting :)

Corollary:

   Folks, start a new thread before posting :)


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

integer's methods

[ast]

Hello

I wonder why calling a method on an integer
doesn't work ?


123.bit_length()

SyntaxError: invalid syntax


123.to_bytes(3, 'big')

SyntaxError: invalid syntax

but it works with a variable


i = 123
i.bit_length()

7


i=123
i.to_bytes(3, 'big')

b'\x00\x00{'

I am working with pyhton 3.5.1

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

Re: integer's methods

[Marko Rauhamaa]

"ast" :

 123.bit_length()
> SyntaxError: invalid syntax

I fell into that trap myself.

CPython's lexical analyzer can't handle a dot after an integer literal
so you must add a space in between "123" and ".".


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

Re: integer's methods

[Igor Korot]

Hi,

On Thu, Aug 18, 2016 at 8:58 AM, ast  wrote:
> Hello
>
> I wonder why calling a method on an integer
> doesn't work ?

123 is not an integer. Its an integer constant. ;-)

Thank you.

>
 123.bit_length()
>
> SyntaxError: invalid syntax
>
 123.to_bytes(3, 'big')
>
> SyntaxError: invalid syntax
>
> but it works with a variable
>
 i = 123
 i.bit_length()
>
> 7
>
 i=123
 i.to_bytes(3, 'big')
>
> b'\x00\x00{'
>
> I am working with pyhton 3.5.1
>
> thx
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: integer's methods

[Lutz Horn]

Am 08/18/2016 um 02:58 PM schrieb ast:

123.bit_length()

SyntaxError: invalid syntax


You are not calling a method here because the parser is not finished.

The parser thinks you want to write a float with the value 1.bit_length
which is not valid Python syntax.

Lutz


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

Re: integer's methods

[ast]

"Marko Rauhamaa"  a écrit dans le message de 
news:87k2fefcyu@elektro.pacujo.net...

"ast" :


123.bit_length()

SyntaxError: invalid syntax


I fell into that trap myself.

CPython's lexical analyzer can't handle a dot after an integer literal
so you must add a space in between "123" and ".".


Marko


Indeed.

Maybe because of a confusion with the decimal point.

Thx 


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

Re: integer's methods

[Lutz Horn]

CPython's lexical analyzer can't handle a dot after an integer literal
so you must add a space in between "123" and ".".


Ok, this works:

>>> 123 .bit_length()
7

But it looks really strange. Let's use a variable instead of an integer 
literal.


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

Re: Error in while loop code for packing items

[GP]

On Thursday, August 18, 2016 at 5:59:43 PM UTC+5:30, Peter Otten wrote:
> GP wrote:
> 
> The error and your second snippet aren't compatible, so I assume the 
> exception is raised by
> 
> > for k in range(0,len(shelf)):
> >   q1=ListDictItem[k]
> >   q2 = ListDictItem.pop(k) #deletes the items that are packed.
> 
> > Error message:Traceback (most recent call last):
> >   File "C:\Project\Python\ReadExcel-xlrd.py", line 201, in 
> > q1=ListDictItem[k]
> > IndexError: list index out of range.
> 
> Take a moment to understand what happens if you iterate over the loop index 
> like above:
> 
> items = ["foo", "bar", "baz"]
> 
> for k in range(len(items)):
> item = items[k]
> print(item)
> items.pop(k)
> 
> You start with k=0, item is set to items[0], i. e. "foo", that is printed 
> and then items.pop(0) removes "foo" from the list which now looks like
> 
> items = ["bar", "baz"]
> 
> Now k=1, item is set to items[1], ie. "baz" ("bar" is never processed), 
> "baz" is printed and then items.pop(1) removes "baz" and the list becomes
> 
> items = ["bar"]
> 
> Now k=2, so when you access items[2] from a list with only one item you get 
> the IndexError. To make similar code work you need a while loop:
> 
> while items:
> item = items.pop(0)
> print(item)
> 
> However, when you really want to remove all items you instead assign a new 
> empty list
> 
> for item in items:
> print(item)
> items = []


Thanks Peter for the information. It helps to find the source of error .

What I wanted was to remove the items that was packed so that the code  can 
check for the next items that match the criteria and then pack those and delete 
them  and keep on repeating until all the items are packed. This is where I am 
getting stuck.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: integer's methods

[BartC]

On 18/08/2016 14:01, Marko Rauhamaa wrote:

"ast" :


123.bit_length()

SyntaxError: invalid syntax


I fell into that trap myself.

CPython's lexical analyzer can't handle a dot after an integer literal
so you must add a space in between "123" and ".".


Or use (123).bit_length() which looks slightly less odd.

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

Re: I am new to python. I have a few questions coming from an armature!

[MRAB]

On 2016-08-18 10:46, Jussi Piitulainen wrote:

Marko Rauhamaa writes:


Jussi Piitulainen wrote:


That looks a bit funny if the "keyword" does not look like a word,
but then programming languages do look funny, so why not:

   (c ? t : e)  # ?-expression

   (c -> t, e)  # ->-expression


That ship has already sailed.


Sorry, what?


You've missed the bus.

The train has left the station.

In other words, you're too late. :-)

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

Re: Error in while loop code for packing items

[MRAB]

On 2016-08-18 14:10, GP wrote:

On Thursday, August 18, 2016 at 5:59:43 PM UTC+5:30, Peter Otten wrote:

GP wrote:


[snip]


However, when you really want to remove all items you instead assign a new
empty list

for item in items:
print(item)
items = []



Thanks Peter for the information. It helps to find the source of error .

What I wanted was to remove the items that was packed so that the code  can 
check for the next items that match the criteria and then pack those and delete 
them  and keep on repeating until all the items are packed. This is where I am 
getting stuck.

The simplest way is to iterate over the list of items and, for each 
item, if it fits the shelf, put it on the shelf, else put it into a list 
of the 'unused' items.


At the end of a pass, you'll have a shelf of items and a list of the 
remaining items.


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

Re: type lookuperror

[Gene Heskett]

On Thursday 18 August 2016 07:28:06 Chris Angelico wrote:

> On Thu, Aug 18, 2016 at 7:55 PM, meInvent bbird  
wrote:
> > actually i would like to remove try except code in all function
> >
> > and i feel that try except code for a large block code can not
> > show which function name , which line number error,
> > if use try except for specified code block to show where it has
> > error it will have many ugly try except code and need many human
> > force to craft the code, i hope that code write once for program to
> > program itself in future.
> >
> > actually this method i ask is not good enough since it will need
> > to add many function wrapper.
>
> You can't get a program to program itself. That's called the
> Singularity [1], and depending on your point of view, it's either
> still in the future, or fundamentally impossible. In any case,
> computers today cannot program themselves.

That is a pretty broad statement to make, considering I have actually 
done it. On an RCA 1802 based (Cosmac Super Elf) computer. Every byte of 
static ram memory in those days (1978) was precious, (4k board kit was 
$250) so rather than having 30 nearly identical copies of a subroutine 
each doing a similar job but with different data, I actually overwrote 3 
or 4 bytes of a single subroutine to change what it did according to 
where it was in the main loop.  So when it was done with that pass, it 
put the original bytes back. Controlling a videotape machine at a tv 
station in northern kalipornia, it was dead stable, running from power 
failure to power failure.  And, I checked about 15 years later, and it 
was still in 10+ times a day use.  If memory was that precious today, it 
would still be a valid method to shrink a complex program.

> So what exactly is it you're wanting? When an exception happens, the
> entire traceback is recorded, and unless you're throwing that away,
> it'll be shown to you. Just let the exception bubble all the way up to
> top level, and then read the traceback. Some IDEs can even help you
> step through the code to see context for each line of traceback;
> ipython is also pretty helpful with reading tracebacks. I advise
> getting to know the tools you have available, rather than trying to
> reinvent the wheel.

Re-inventing the wheel is not required when all it needs is a new valve 
stem.

> ChrisA
>
> [1] https://en.wikipedia.org/wiki/Technological_singularity


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: type lookuperror

[Chris Angelico]

On Fri, Aug 19, 2016 at 12:02 AM, Gene Heskett  wrote:
> On Thursday 18 August 2016 07:28:06 Chris Angelico wrote:
>
>> On Thu, Aug 18, 2016 at 7:55 PM, meInvent bbird 
> wrote:
>> > and i feel that try except code for a large block code can not
>> > show which function name , which line number error,
>> > if use try except for specified code block to show where it has
>> > error it will have many ugly try except code and need many human
>> > force to craft the code, i hope that code write once for program to
>> > program itself in future.
>>
>> You can't get a program to program itself. That's called the
>> Singularity [1], and depending on your point of view, it's either
>> still in the future, or fundamentally impossible. In any case,
>> computers today cannot program themselves.
>
> That is a pretty broad statement to make, considering I have actually
> done it. [chomp details]

What you described there is an example of metaprogramming. The
thoughts behind the code all existed prior to the code modifying its
own bytes in memory. It's a fancy form of the same sorts of things
that can be done with monkeypatching and similar techniques.

What the OP was looking for was "I want my program to be able to debug
itself". That means the program has to be smart enough to figure out
its own problems. Self-modifying code isn't anywhere near that level
of intelligence.

(That's not to say self-modifying code isn't impressive, in its way. I
have great respect for it. But you have to plan it out in advance,
ergo it's not having the program program itself.)

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

Re: type lookuperror

[Marko Rauhamaa]

Chris Angelico :
> What the OP was looking for was "I want my program to be able to debug
> itself". That means the program has to be smart enough to figure out
> its own problems. Self-modifying code isn't anywhere near that level
> of intelligence.

You are right that we're not nearly there yet (although genetic
programming is a bit of a similar thing).

What is needed is an automated methodology to derive algorithmic
solutions to formally specified features. Since there are only a handful
of tools in a programmer's toolbox, that objective doesn't seem at all
impossible. The big question is, is it possible to specify features
formally without actually coding them?


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

Re: type lookuperror

[Chris Angelico]

On Fri, Aug 19, 2016 at 1:28 AM, Marko Rauhamaa  wrote:
> What is needed is an automated methodology to derive algorithmic
> solutions to formally specified features. Since there are only a handful
> of tools in a programmer's toolbox, that objective doesn't seem at all
> impossible. The big question is, is it possible to specify features
> formally without actually coding them?

If you're specifying them formally, you're probably coding them. Any
form sufficiently well-defined for a program to analyze is basically
code already. It might be a goal-based syntax rather than action-based
(eg contrast SQL's way of saying "these are the rows I want" with
classic imperative programming), but it's still code, it's still
software, it's still not the Singularity.

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

Re: type lookuperror

[Larry Martell]

On Thu, Aug 18, 2016 at 10:02 AM, Gene Heskett  wrote:
> On Thursday 18 August 2016 07:28:06 Chris Angelico wrote:
>
>> On Thu, Aug 18, 2016 at 7:55 PM, meInvent bbird 
> wrote:
>> > actually i would like to remove try except code in all function
>> >
>> > and i feel that try except code for a large block code can not
>> > show which function name , which line number error,
>> > if use try except for specified code block to show where it has
>> > error it will have many ugly try except code and need many human
>> > force to craft the code, i hope that code write once for program to
>> > program itself in future.
>> >
>> > actually this method i ask is not good enough since it will need
>> > to add many function wrapper.
>>
>> You can't get a program to program itself. That's called the
>> Singularity [1], and depending on your point of view, it's either
>> still in the future, or fundamentally impossible. In any case,
>> computers today cannot program themselves.
>
> That is a pretty broad statement to make, considering I have actually
> done it. On an RCA 1802 based (Cosmac Super Elf) computer. Every byte of
> static ram memory in those days (1978) was precious, (4k board kit was
> $250) so rather than having 30 nearly identical copies of a subroutine
> each doing a similar job but with different data, I actually overwrote 3
> or 4 bytes of a single subroutine to change what it did according to
> where it was in the main loop.  So when it was done with that pass, it
> put the original bytes back. Controlling a videotape machine at a tv
> station in northern kalipornia, it was dead stable, running from power
> failure to power failure.  And, I checked about 15 years later, and it
> was still in 10+ times a day use.  If memory was that precious today, it
> would still be a valid method to shrink a complex program.

Freshman year of college, 1977, final exam for a Fortran class. One of
the questions was to write some program but only use some specified
small amount of memory. I do not think anyone in the class was able to
do it. The only way to do it was to write self modifying code,
something that we had never covered in class.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[Marko Rauhamaa]

Chris Angelico :

> On Fri, Aug 19, 2016 at 1:28 AM, Marko Rauhamaa  wrote:
>> What is needed is an automated methodology to derive algorithmic
>> solutions to formally specified features. Since there are only a
>> handful of tools in a programmer's toolbox, that objective doesn't
>> seem at all impossible. The big question is, is it possible to
>> specify features formally without actually coding them?
>
> If you're specifying them formally, you're probably coding them. Any
> form sufficiently well-defined for a program to analyze is basically
> code already. It might be a goal-based syntax rather than action-based
> (eg contrast SQL's way of saying "these are the rows I want" with
> classic imperative programming), but it's still code, it's still
> software, it's still not the Singularity.

Yeah, I believe truly conscious machines will arise without being
designed through technological evolution. First they'll develop
electronics that can simulate brain cells; the clumsy gadgets will be
used to replaced cells damaged by Parkinson's or Alzheimer's. Then,
healthy people will start enhancing their brain functions by using the
same technology. Over time, wetware will be replaced by hardware, and
the hardware, in turn, will migrate to the cloud.

Steven Lisberger saw this already way back: https://en.wikipedia.org/wiki/Tron>.

Once we run on Google's server farms, we can back ourselves up as
snapshots and clone ourselves indefinitely. That will be one big
identity crisis. Even further along, maybe the intercommunication
between the virtual selves will blur the lines between individuals, and
we'll merge into a pantheistic Nirvana (or infernal pandemonium).


Marko


PS Long before, though, we'll likely get direct communication ports to
our brains and be liberated from mice and keyboards (first) and speakers
and displays (a bit later).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[Chris Angelico]

On Fri, Aug 19, 2016 at 2:21 AM, Marko Rauhamaa  wrote:
>
> Yeah, I believe truly conscious machines will arise without being
> designed through technological evolution. First they'll develop
> electronics that can simulate brain cells; the clumsy gadgets will be
> used to replaced cells damaged by Parkinson's or Alzheimer's. Then,
> healthy people will start enhancing their brain functions by using the
> same technology. Over time, wetware will be replaced by hardware, and
> the hardware, in turn, will migrate to the cloud.

http://mtgsalvation.gamepedia.com/Esper

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

Re: I am new to python. I have a few questions coming from an armature!

[Terry Reedy]

On 8/18/2016 5:32 AM, Steven D'Aprano wrote:


Beginners often do not understand that the body of a lambda expression
is evaluated in a new local namespace, and only when the resulting
function is called, the same as with a def statement.  They then neglect
to capture current values when writing lambda expressions in a for loop.


Sure. But since the behaviour of def functions and lambda functions are
identical, writing a named def won't solve that problem.


It will if people do not make the same mental mistake when writing a 
def, because they think def functions and 'lambdas' behave differently.


I can't remember every seeing "my def function in a loop does not work 
right" while "my lambda in a loop does not work right" is distressingly 
common.  What I don't know is whether the sparsity of the former type of 
report is because those subject to the error get it right when they use 
def in a loop or because they never use def in a loop.


--
Terry Jan Reedy

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

Re: I am new to python. I have a few questions coming from an armature!

[Chris Angelico]

On Fri, Aug 19, 2016 at 3:00 AM, Terry Reedy  wrote:
> On 8/18/2016 5:32 AM, Steven D'Aprano wrote:
>
>>> Beginners often do not understand that the body of a lambda expression
>>> is evaluated in a new local namespace, and only when the resulting
>>> function is called, the same as with a def statement.  They then neglect
>>> to capture current values when writing lambda expressions in a for loop.
>>
>>
>> Sure. But since the behaviour of def functions and lambda functions are
>> identical, writing a named def won't solve that problem.
>
>
> It will if people do not make the same mental mistake when writing a def,
> because they think def functions and 'lambdas' behave differently.
>
> I can't remember every seeing "my def function in a loop does not work
> right" while "my lambda in a loop does not work right" is distressingly
> common.  What I don't know is whether the sparsity of the former type of
> report is because those subject to the error get it right when they use def
> in a loop or because they never use def in a loop.

The latter. People who are confused about lambda in a loop are not
magically unconfused by def in a loop; in fact, I'd expect to see
*more* confusion, because those same people are likely to be confused
by the fact that a "declaration" can be done more than once and have
different effects. That is to say, a lambda function looks like it's
being created at the point where you use it, but a def function looks
like a declaration, which is independent of loops and stuff. I don't
have actual stats on how many people are confused by each, but I know
both points do cause confusion. Having def statements inside loops is
definitely [1] rarer than using lambda expressions inside loops.

ChrisA

[1] Pun intended. And I'm not sorry.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I am new to python. I have a few questions coming from an armature!

[Jussi Piitulainen]

MRAB writes:

> On 2016-08-18 10:46, Jussi Piitulainen wrote:
>> Marko Rauhamaa writes:
>>
>>> Jussi Piitulainen wrote:
>>>
 That looks a bit funny if the "keyword" does not look like a word,
 but then programming languages do look funny, so why not:

(c ? t : e)  # ?-expression

(c -> t, e)  # ->-expression
>>>
>>> That ship has already sailed.
>>
>> Sorry, what?
>>
> You've missed the bus.
>
> The train has left the station.
>
> In other words, you're too late. :-)

Yes, I understood _that_. I just don't understand how it can be too late
to observe that "?-expression" looks a bit funny but not so funny that
it couldn't be used to refer to such expressions.

But never mind, even I have more interesting issues to think about :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[Lawrence D’Oliveiro]

On Friday, August 19, 2016 at 3:10:26 AM UTC+12, Chris Angelico wrote:
> What the OP was looking for was "I want my program to be able to debug
> itself". That means the program has to be smart enough to figure out
> its own problems.

Maybe it is, it just doesn’t agree with you on what those problems are. ;)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: integer's methods

[Lawrence D’Oliveiro]

On Friday, August 19, 2016 at 12:59:09 AM UTC+12, ast wrote:
> I wonder why calling a method on an integer
> doesn't work ?

Sure it does.

>>> 2 + 5
7
>>> (2).__add__(5)
7
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[meInvent bbird]

On Friday, August 19, 2016 at 5:37:32 AM UTC+8, Lawrence D’Oliveiro wrote:
> On Friday, August 19, 2016 at 3:10:26 AM UTC+12, Chris Angelico wrote:
> > What the OP was looking for was "I want my program to be able to debug
> > itself". That means the program has to be smart enough to figure out
> > its own problems.
> 
> Maybe it is, it just doesn’t agree with you on what those problems are. ;)


a company which write siri in iphone, has already wrote a program
which can write program itself after the program talks with users

it seems possible,

i find many default function when using dir(function) to see
so i guess that these default functions in openstack have its existence reason 
which i guess for program itself.

how to append a function or code in runtime in python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type lookuperror

[Steve D'Aprano]

On Fri, 19 Aug 2016 11:43 am, meInvent bbird wrote:

> a company which write siri in iphone, has already wrote a program
> which can write program itself after the program talks with users
> 
> it seems possible,

You are asking about self-modifying code, which is a terrible idea.

Siri uses machine learning, which is a difference concept.


> i find many default function when using dir(function) to see
> so i guess that these default functions in openstack have its existence
> reason which i guess for program itself.

I'm afraid I don't understand the question.


> how to append a function or code in runtime in python?

Just write the function, and then call it.

If you write a function:

def foo(x):
   return x + 1


now you can use foo() like any other function, len(), str(), etc.


Have you done the Python tutorial? It sounds like you should consider doing
the tutorial.

For version 3:

https://docs.python.org/3/tutorial/

For version 2:

https://docs.python.org/2/tutorial/





-- 
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: type lookuperror

[Gregory Ewing]

Chris Angelico wrote:

You can't get a program to program itself. That's called the
Singularity [1], and depending on your point of view, it's either
still in the future, or fundamentally impossible.


Quite likely it's provably impossible. A computer that
can program itself for anything you might want it to
do is equivalent to having a very general-purpose
program that is capable of solving any problem. That's
probably in contravention of Goedel's incompleteness
theorem or something like that.

Anyway, I wouldn't want such a computer -- it would
take away all the fun!

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

Re: type lookuperror

[Gregory Ewing]

Chris Angelico wrote:

If you're specifying them formally, you're probably coding them. Any
form sufficiently well-defined for a program to analyze is basically
code already.


Yes, I think that once a specification language crosses
a certain threshold of complexity, it becomes just as
difficult to debug as a program -- so all you've done
is invent another programming language.

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

Re: type lookuperror

[Steve D'Aprano]

On Fri, 19 Aug 2016 02:30 am, Chris Angelico wrote:

> On Fri, Aug 19, 2016 at 2:21 AM, Marko Rauhamaa  wrote:
>>
>> Yeah, I believe truly conscious machines will arise without being
>> designed through technological evolution. First they'll develop
>> electronics that can simulate brain cells; the clumsy gadgets will be
>> used to replaced cells damaged by Parkinson's or Alzheimer's. Then,
>> healthy people will start enhancing their brain functions by using the
>> same technology. Over time, wetware will be replaced by hardware, and
>> the hardware, in turn, will migrate to the cloud.
> 
> http://mtgsalvation.gamepedia.com/Esper

And when all the hardware is migrated to "the cloud" (stupid marketing speak
for "a bunch of computers that you don't control connected to the
internet"), what exactly will "the cloud" be running on? Moonbeams and
kitten purrs?

Anyone who puts their own mental capacity in the hands of an external entity
they cannot control (*especially* if it is an unregulated or self-regulated
for-profit corporation) will so deserve it when that entity threatens to
cut off 95% of their intelligence unless they upgrade to the Premium "Not A
Drooling Moron" service.

Personally I think it would be hilarious to see what happens when the
wireless connection to "the cloud" go down, and people's intellectually
capacity drop so low that they *literally cannot notice* that they're
missing anything. Denial Of Service attacks will be *hilarious*.

Of course, for this scenario to be plausible will require a much more
advanced understanding of human thought processes, one sufficiently
advanced that these cloud "brain providers" would be more than capable of
invisibly controlling your thoughts. At the basic end, they could inject
advertisements into your visual and auditory cortex without the need to go
through your eyes. By why bother with advertisements aimed to persuade you
to buy Buzz Cola when they can just inject the thought into your brain that
you want to buy Buzz Cola more than anything in the world?

Of course, the better Cloud Brain Providers will offer a premium service
where, for an extra price, they guarantee[1] not to inject thoughts into
your Cloud Brain. Naturally, except for thoughts required for the
maintenance and upkeep of the service ("I must pay the CBP bill today"),
thoughts you have previously Liked or expressed interest in, thoughts
mandated by law, thoughts from companies that you have an existing business
arrangement, and other exempted organisations such as approved charities
and religions.

The best part of it is, how could you tell whether or not your CBP is living
up to their service guarantees? If they're not, you literally will be
incapable of thinking that you are unsatisfied with their service.

I can hardly wait.






[1] Conditions apply.

-- 
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: integer's methods

[Steve D'Aprano]

On Thu, 18 Aug 2016 10:58 pm, ast wrote:

> Hello
> 
> I wonder why calling a method on an integer
> doesn't work ?
> 
 123.bit_length()
> SyntaxError: invalid syntax


Because Python thinks you are writing a float, and "b" is not a valid digit.

Try:


(123).bit_length()

123 .bit_length()


instead.


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