Re: generator/coroutine terminology

[Marko Rauhamaa]

Steven D'Aprano :

> Marko Rauhamaa wrote:
>
>> Your 'factory' is a:
>> 
>> generator
>> A function which returns an iterator.
>> https://docs.python.org/3/glossary.html>
>
> That glossary entry is misleading, or at least incomplete, and it
> fails to match the way "generator" is used by actual Python
> programmers.

I am an actual Python programmer (I develop Python programs) and my
definitive source for Python is the documentation. If there is an error
in the documentation, I would very much like it to be corrected.

> A generator (function) may be a function which returns an iterator,
> but not all functions that return iterators are generators, and in
> some ways returning an iterator is the *least* interesting part of
> what makes a generator a generator.
>
> What distinguishes a generator from a regular function is the use of
> `yield`. Any definition which fails to mention that fact is useless.

The language reference had better use more precise language. It *is* the
definitive source, after all.

> Like many English words, we have two meanings for "generator":
>
> (1) A function containing the `yield` keyword, or "generator-function".
>
> (2) The result of calling such a function, an instance of
> types.GeneratorType. PEP 255 calls that a "generator-iterator", but
> that name doesn't appear to have caught on anywhere.
>
> If people can cope with the difference between a TV program and a
> computer program, they can cope with "generator" having two meanings,
> especially since we have ways to disambiguate between the two when
> needed.

I think that is untenable when you talk about a programming language.

>> I don't think you should read much into what str(obj) returns. It's
>> not much more than a random printable some CPython coder has cooked
>> up in the heat of the moment.
>
> I think that is completely wrong. The repr() and str() of generator
> instances is hardly "random", it reflects the consensus of the PEP
> authors and the Python core developers, in particular the BDFL Guido
> who approved the PEP, that the type of object it is should be called
> "generator".

Be that as it may,

   https://docs.python.org/3/reference/>

and

   https://docs.python.org/3/library/>

are the definitive sources for Python application programmers.

Or is there a better reference you would recommend?


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

Re: Python 2 to 3 conversion - embrace the pain

[Marko Rauhamaa]

John Nagle :

>   I'm approaching the end of converting a large system from Python 2
> to Python 3. Here's why you don't want to do this.

A nice report, thanks. Shows that the slowness of Python 3 adoption is
not only social inertia.


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

Re: generator/coroutine terminology

[Mark Lawrence]

On 14/03/2015 07:54, Marko Rauhamaa wrote:

Steven D'Aprano :


Marko Rauhamaa wrote:


Your 'factory' is a:

 generator
 A function which returns an iterator.
 https://docs.python.org/3/glossary.html>


That glossary entry is misleading, or at least incomplete, and it
fails to match the way "generator" is used by actual Python
programmers.


I am an actual Python programmer (I develop Python programs) and my
definitive source for Python is the documentation. If there is an error
in the documentation, I would very much like it to be corrected.



Five minutes work for you (singular) on the bug tracker.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: generator/coroutine terminology

[Marko Rauhamaa]

Mark Lawrence :

> On 14/03/2015 07:54, Marko Rauhamaa wrote:
>> I am an actual Python programmer (I develop Python programs) and my
>> definitive source for Python is the documentation. If there is an
>> error in the documentation, I would very much like it to be
>> corrected.
>
> Five minutes work for you (singular) on the bug tracker.

I haven't determined that there is an error. I couldn't because to me,
the documentation defines right and wrong.

The only sign of discord so far has been between the return value of
str() and the language of the documentation. The return values of str()
and repr() are not defined very precisely:

 object.__repr__(self)
Called by the repr() built-in function to compute the “official”
string representation of an object. If at all possible, this should
look like a valid Python expression that could be used to recreate
an object with the same value (given an appropriate environment). If
this is not possible, a string of the form <...some useful
description...> should be returned. The return value must be a
string object. [...]

 object.__str__(self)
Called by str(object) and the built-in functions format() and
print() to compute the “informal” or nicely printable string
representation of an object. The return value must be a string
object.

Thus one shouldn't read too much into what str() and repr() return. In
particular, there is no requirement that two valid Python
implementations ought to return similar-looking strings.


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

Re: Python 2 to 3 conversion - embrace the pain

[Mark Lawrence]

On 13/03/2015 21:08, John Nagle wrote:

   I'm approaching the end of converting a large system from Python 2 to
Python 3.  Here's why you don't want to do this.



One reason why you should 
https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon


Of course I understand the problems of time when it comes to porting 
code.  Taking this Tue Mar 21 06:19:36 CET 2006, the time of the first 
email on the Python 3000 development mailing list, as the start date for 
Python 3, developers have only had nine years to port their libraries. 
Rome wasn't destroyed in a day? :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: The idle gui

[Dave Angel]

On 03/13/2015 09:24 PM, Steven D'Aprano wrote:

sohcahto...@gmail.com wrote:



We need more information than just "It doesn't work".  You wouldn't go to
a car mechanic and say "It makes a funny noise", would you?  No.


Actually, most likely yes.It's remarkably hard to describe noises, and often
difficult to pin-point where they come from. My wife and I can sit in the
same car, listening to the same noise, and she swears it is coming from the
front left and I'm sure its coming from the rear right. (Invariably she's
correct.)

But at least the car mechanic can jump in the car and take it for a drive.



Not if you don't take it to him.  If you just call him on the phone, and 
say "Jimmy doesn't work" he doesn't even know what make and model the 
vehicle is.  Or whether it's even a car.  Maybe "it" is a son who 
refuses to get a job.



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

Re: The idle gui

[Chris Angelico]

On Sat, Mar 14, 2015 at 12:35 PM, Dave Angel  wrote:
> Not if you don't take it to him.  If you just call him on the phone, and say
> "Jimmy doesn't work" he doesn't even know what make and model the vehicle
> is.  Or whether it's even a car.  Maybe "it" is a son who refuses to get a
> job.

In the OP's defense, we were at least told that the "idle gui" was the
thing that didn't work. So unless you named your son "gui", we can
safely assume that this isn't the case :)

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

Module/lib for controlling a terminal program using redrawing?

[Jason Heeris]

I am trying to automate the use of some old, in-house terminal-based
programs that use screen redrawing for their interface. This includes
single line redrawing (eg. using '\r' and overwriting), complete screen
clearing, and fine-grained cursor movement and overwriting (probably not
all in the same program at the same time though).

Is there a module/library that can help me with this?

I know of pexpect, but that seems more oriented towards line-by-line
prompts that don't involve redraws (eg. login prompt, then password prompt
on a new line). Think instead of trying to automate applications like
emacs, aptitude or even nethack that redraw sections of the screen without
making the terminal scroll.

This automation requires more than just sending a set of keystrokes, but
also reading what is displayed on screen and making decisions based up on
that.

Is there a library that can abstract the received redrawing activity so I
don't have to even know if the application has, eg. used a carriage return
or some other kind of cursor movement? Is there a way to just ask "if this
were to be run in an ANSI terminal, what would be in each cell?"

Python 2 or 3 are both fine, external packages are fine, but it has to work
on Linux (eg. Ubuntu 14.04 or later, Debian Wheezy or later).

Any pointers appreciated.

Cheers,
Jason
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Module/lib for controlling a terminal program using redrawing?

[Dave Angel]

On 03/14/2015 06:50 AM, Jason Heeris wrote:

I am trying to automate the use of some old, in-house terminal-based
programs that use screen redrawing for their interface. This includes
single line redrawing (eg. using '\r' and overwriting), complete screen
clearing, and fine-grained cursor movement and overwriting (probably not
all in the same program at the same time though).

Is there a module/library that can help me with this?


https://docs.python.org/3/howto/curses.html

That's in the standard library for both Python2 and 3.  I don't know if 
it'll do everything you need, but if not, there are also various 
wrappers for curses that can be found with a google search.



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

Re: The idle gui

[Rustom Mody]

On Saturday, March 14, 2015 at 3:28:11 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Mar 14, 2015 at 12:35 PM, Dave Angel  wrote:
> > Not if you don't take it to him.  If you just call him on the phone, and say
> > "Jimmy doesn't work" he doesn't even know what make and model the vehicle
> > is.  Or whether it's even a car.  Maybe "it" is a son who refuses to get a
> > job.
> 
> In the OP's defense, we were at least told that the "idle gui" was the
> thing that didn't work. So unless you named your son "gui", we can
> safely assume that this isn't the case :)
> 
> ChrisA

Saw this yesterday on the Haskell list:

"How do I use lens confusing?"
"You mean 'it's confusing'?"
"No, I mean Control.Lens.Traversal.confusing"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Odd ValueError using float

[emile]

On 03/13/2015 08:09 PM, Chris Angelico wrote:

On Sat, Mar 14, 2015 at 1:33 PM, Paul Rubin  wrote:

emile  writes:

*** NameError: name 'val' is not defined
(Pdb) l
139 try:
140 val = round(float(decval),1)
141 except:
142 import pdb; pdb.set_trace()


If 'float' or 'round' throw an exception, the assignment to 'val' never
happens, so 'val' is undefined.  Try examining the value of 'decval' in
the debugger to see what is making the conversion fail.


That's exactly what the OP did :) Trouble is, it didn't help, because
it sure looked as if decval was the string '4'. My best guess was -
and is - that it's not just a string. We're looking at an SQL
interface routine here, so it may be that there's a string subclass
that length-limits itself, on the assumption that it's going into a
fixed-length database field.


It ran almost to completion before generating the error again --

(Pdb) decval
'4'
(Pdb) type(decval)

(Pdb) len(decval)
1
(Pdb) int(decval)
*** ValueError: invalid literal for int() with base 10: '41.703'

So there's still something amiss.

Emile

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

Re: generator/coroutine terminology

[Rustom Mody]

On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano wrote:
> 
> A generator (function) may be a function which returns an iterator,...

I find "generator-function" misleading in the same way that "pineapple" 
misleadingly suggests "apple that grows on pines"

A builtin function is a function in the builtin (or builtins -- can never 
remember) module
A pure function is function that does not assign or mutate non-locals
A Steven-function is a function that presumably Steven wrote 

However a "generator function" is a weird sort of function (at best).
Not regarding it as a function is IMO more reasonable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Odd ValueError using float

[Chris Angelico]

On Sun, Mar 15, 2015 at 2:28 AM, emile  wrote:
> It ran almost to completion before generating the error again --
>
> (Pdb) decval
> '4'
> (Pdb) type(decval)
> 
> (Pdb) len(decval)
> 1
> (Pdb) int(decval)
> *** ValueError: invalid literal for int() with base 10: '41.703'
>
> So there's still something amiss.

Compare these two lines' outputs:

print("str %d, int %d" % (id(str), id(int)))
print("str %d, int %d" % (id(type("")), id(type(0)))

Any difference in id would indicate that the names have been shadowed
- seems unlikely, but worth checking. And then, just to be absolutely
sure:

type(decval) is type("")

There is another, and very nasty, possibility. If you're working with
a C extension that has a refcount bug in it, all sorts of bizarre
things can happen - crucial type objects getting garbage collected,
objects getting disposed of and others taking their places, all kinds
of weird and wonderful things. Normally that'll eventually cause a
crash, but who knows...

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

Re: generator/coroutine terminology

[Chris Angelico]

On Sun, Mar 15, 2015 at 2:29 AM, Rustom Mody  wrote:
> However a "generator function" is a weird sort of function (at best).
> Not regarding it as a function is IMO more reasonable.

But it *is* a function. You call it, possibly with positional and/or
keyword arguments, and you get back a returned object. How is this
different from any other function? (Yes, by this definition a class
could be called an "object function". But the line is already somewhat
blurry; if I've read my history correctly, "int" used to be a
function, but now it's a type. A class is really just a special type
of factory function, just as a generator function is.)

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

Re: generator/coroutine terminology

[Rustom Mody]

On Saturday, March 14, 2015 at 8:59:22 PM UTC+5:30, Rustom Mody wrote:
> On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano wrote:
> > 
> > A generator (function) may be a function which returns an iterator,...
> 
> I find "generator-function" misleading in the same way that "pineapple" 
> misleadingly suggests "apple that grows on pines"
> 
> A builtin function is a function in the builtin (or builtins -- can never 
> remember) module
> A pure function is function that does not assign or mutate non-locals
> A Steven-function is a function that presumably Steven wrote 
> 
> However a "generator function" is a weird sort of function (at best).
> Not regarding it as a function is IMO more reasonable.

Another analogy somewhat closer home than pineapples.
In Pascal there are procedures and functions.
Even in the venerable Fortran there are subroutine-subprogram and 
(sub)function-subprogram.

C took the stupid approach of just throwing out one of these.
A decade of troubles was enough to convince people that it was needed and the
mysterious 'void-returning' function was introduced to simulate procedures

Causing all sorts of unnecessary confusions:
An int-function returns int and a char*-functions returns char*.
Does a void-function return void??
No a void function doesn't return anything!
Ah So a void function does a longjmp?

All of which is to say that in retrospect we need (at least in imperative 
programming) procedures and functions.

Best if the language supports them

If not, then we need them all the more in the conceptual ontology we use to
build programs.

Analogously we need the generator 'design-pattern' as well as the function
design-pattern. Conflating one as a special case of the other is a recipe for
confusion
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Odd ValueError using float

[Peter Otten]

emile wrote:

> On 03/13/2015 08:09 PM, Chris Angelico wrote:
>> On Sat, Mar 14, 2015 at 1:33 PM, Paul Rubin 
>> wrote:
>>> emile  writes:
 *** NameError: name 'val' is not defined
 (Pdb) l
 139 try:
 140 val = round(float(decval),1)
 141 except:
 142 import pdb; pdb.set_trace()
>>>
>>> If 'float' or 'round' throw an exception, the assignment to 'val' never
>>> happens, so 'val' is undefined.  Try examining the value of 'decval' in
>>> the debugger to see what is making the conversion fail.
>>
>> That's exactly what the OP did :) Trouble is, it didn't help, because
>> it sure looked as if decval was the string '4'. My best guess was -
>> and is - that it's not just a string. We're looking at an SQL
>> interface routine here, so it may be that there's a string subclass
>> that length-limits itself, on the assumption that it's going into a
>> fixed-length database field.
> 
> It ran almost to completion before generating the error again --
> 
> (Pdb) decval
> '4'
> (Pdb) type(decval)
> 
> (Pdb) len(decval)
> 1
> (Pdb) int(decval)
> *** ValueError: invalid literal for int() with base 10:
> '41.703'
> 
> So there's still something amiss.

Why are you checking

int(decval)

when the actual failing expression is

round(float(decval),1)

? Try to evaluate the latter in the debugger, and if that gives no clue 
change

 139 try:
 140 val = round(float(decval),1)
 141 except:
 142 import pdb; pdb.set_trace()

to just

val = round(float(decval), 1)

to get a meaningful traceback and post that.

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

Re: generator/coroutine terminology

[Chris Angelico]

On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody  wrote:
> Causing all sorts of unnecessary confusions:
> An int-function returns int and a char*-functions returns char*.
> Does a void-function return void??
> No a void function doesn't return anything!
> Ah So a void function does a longjmp?
>
> All of which is to say that in retrospect we need (at least in imperative 
> programming) procedures and functions.
>
> Best if the language supports them

Python has a broad concept of "functions/methods that return something
interesting" and "functions/methods that always return None". (The
distinction often corresponds to non-mutator and mutator methods, but
that's just convention.)

Pike has void and non-void functions, but you can sometimes trick the
system into giving you the return value of a void function. (Spoiler:
It'll be the integer 0.)

HTTP has some responses which contain no body (eg 304 NOT MODIFIED) as
well as many which do.

Ditto many other languages and protocols.

In each case, there's no _real_ distinction between functions and
procedures (Pike follows C in having "void functions", but they're
still functions), and I don't see any evidence indicating that this
has damaged the languages or protocols concerned - can you show
otherwise?

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

Re: generator/coroutine terminology

[Rustom Mody]

On Saturday, March 14, 2015 at 9:45:10 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody wrote:
> > Causing all sorts of unnecessary confusions:
> > An int-function returns int and a char*-functions returns char*.
> > Does a void-function return void??
> > No a void function doesn't return anything!
> > Ah So a void function does a longjmp?
> >
> > All of which is to say that in retrospect we need (at least in imperative 
> > programming) procedures and functions.
> >
> > Best if the language supports them
> 
> Python has a broad concept of "functions/methods that return something
> interesting" and "functions/methods that always return None". (The
> distinction often corresponds to non-mutator and mutator methods, but
> that's just convention.)

With due respect Chris, you are confused:

Sure any effective *pythonista* (who writes useful python) will have this 
concept.

Python (as against pythonistas) has no such concept¹ as "function that ALWAYS
returns None"

Consider this foo

>>> def foo(x):
...  if x>0: return x-1
... 
>>> foo(3)
2
>>> foo(-1)
>>>

As best as I can see python makes no distinction between such a foo and 
the more usual function/methods that have no returns.
You can I can talk about these and distinguish them
Python has no clue about it.



Leaving aside latest type-annotation proposal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: generator/coroutine terminology

[Chris Angelico]

On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody  wrote:
> As best as I can see python makes no distinction between such a foo and
> the more usual function/methods that have no returns.
> You can I can talk about these and distinguish them
> Python has no clue about it.

But what support is actually needed? Look, I can write functions that
return values:

def square(x):
return x*x

four = square(2)

and functions that don't:

def save_to_file(fn):
with open(fn, "w") as f:
f.write(stuff)
f.write(more_stuff)

save_to_file("/tmp/asdf")

Who cares that the second one actually returns None and then ignores
that? It's not returning anything, it's not using the function return
value. This is, in effect, a procedure.

How is Python worse off for doing things this way rather than having a
true "function with no return value" or "procedure" concept?

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

Re: generator/coroutine terminology

[Mark Lawrence]

On 14/03/2015 16:33, Rustom Mody wrote:

On Saturday, March 14, 2015 at 9:45:10 PM UTC+5:30, Chris Angelico wrote:

On Sun, Mar 15, 2015 at 2:59 AM, Rustom Mody wrote:

Causing all sorts of unnecessary confusions:
An int-function returns int and a char*-functions returns char*.
Does a void-function return void??
No a void function doesn't return anything!
Ah So a void function does a longjmp?

All of which is to say that in retrospect we need (at least in imperative 
programming) procedures and functions.

Best if the language supports them


Python has a broad concept of "functions/methods that return something
interesting" and "functions/methods that always return None". (The
distinction often corresponds to non-mutator and mutator methods, but
that's just convention.)


With due respect Chris, you are confused:

Sure any effective *pythonista* (who writes useful python) will have this 
concept.

Python (as against pythonistas) has no such concept¹ as "function that ALWAYS
returns None"

Consider this foo


def foo(x):

...  if x>0: return x-1
...

foo(3)

2

foo(-1)



As best as I can see python makes no distinction between such a foo and
the more usual function/methods that have no returns.
You can I can talk about these and distinguish them
Python has no clue about it.



Python *ALWAYS* returns None for any path through a function that 
doesn't specify a return value.  Taking your example.


>>> def foo(x):
... if x>0: return x-1
...
>>> import dis
>>> dis.dis(foo)
  2   0 LOAD_FAST0 (x)
  3 LOAD_CONST   1 (0)
  6 COMPARE_OP   4 (>)
  9 POP_JUMP_IF_FALSE   20
 12 LOAD_FAST0 (x)
 15 LOAD_CONST   2 (1)
 18 BINARY_SUBTRACT
 19 RETURN_VALUE
>>   20 LOAD_CONST   0 (None)
 23 RETURN_VALUE

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Odd ValueError using float

[emile]

On 03/14/2015 09:08 AM, Peter Otten wrote:

emile wrote:


On 03/13/2015 08:09 PM, Chris Angelico wrote:

On Sat, Mar 14, 2015 at 1:33 PM, Paul Rubin 
wrote:

emile  writes:

*** NameError: name 'val' is not defined
(Pdb) l
139 try:
140 val = round(float(decval),1)
141 except:
142 import pdb; pdb.set_trace()


If 'float' or 'round' throw an exception, the assignment to 'val' never
happens, so 'val' is undefined.  Try examining the value of 'decval' in
the debugger to see what is making the conversion fail.


That's exactly what the OP did :) Trouble is, it didn't help, because
it sure looked as if decval was the string '4'. My best guess was -
and is - that it's not just a string. We're looking at an SQL
interface routine here, so it may be that there's a string subclass
that length-limits itself, on the assumption that it's going into a
fixed-length database field.


It ran almost to completion before generating the error again --

(Pdb) decval
'4'
(Pdb) type(decval)

(Pdb) len(decval)
1
(Pdb) int(decval)
*** ValueError: invalid literal for int() with base 10:
'41.703'

So there's still something amiss.


Why are you checking

int(decval)



because it sure smells like int should work:

(Pdb) "3"

when the actual failing expression is

round(float(decval),1)

? Try to evaluate the latter in the debugger, and if that gives no clue
change


139 try:
140 val = round(float(decval),1)
141 except:
142 import pdb; pdb.set_trace()


to just

val = round(float(decval), 1)

to get a meaningful traceback and post that.


I don't get a traceback -- it spews:

Fatal Python error: deletion of interned string failed

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information.

then crashes and I get a Microsoft pop-up that says python.exe has 
encountered a problem and needs to close.


Emile




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

Re: generator/coroutine terminology

[Dave Angel]

On 03/14/2015 12:51 PM, Chris Angelico wrote:

On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody  wrote:

As best as I can see python makes no distinction between such a foo and
the more usual function/methods that have no returns.
You can I can talk about these and distinguish them
Python has no clue about it.


But what support is actually needed? Look, I can write functions that
return values:

def square(x):
 return x*x

four = square(2)

and functions that don't:

def save_to_file(fn):
 with open(fn, "w") as f:
 f.write(stuff)
 f.write(more_stuff)

save_to_file("/tmp/asdf")

Who cares that the second one actually returns None and then ignores
that? It's not returning anything, it's not using the function return
value. This is, in effect, a procedure.

How is Python worse off for doing things this way rather than having a
true "function with no return value" or "procedure" concept?



And in C (at least the 80x86 implementations that I used) returns a 
value from a void function as well.  The value is an undefined int 
value, whatever the AX (EAX) register happened to contain.  The check 
that you didn't use such a value is made at compile time.


Further, in the original C definition, if you didn't define a return 
value, it was assumed to be int. And if you didn't define the arguments, 
they were assumed to be right.  In the "C calling convention," the 
caller was responsible for popping off the arguments, since the called 
function didn't necessarily have a clue how many there were.  Then 
later, for "efficiency reasons," they came up with the "Pascal calling 
convention," where the callee popped the arguments.  It perhaps was 
related to the fact that the 80x86 instruction set had the "return N" 
instruction which decremented the call stack pointer an additional 
amount, at the same time as doing the return.


I think the Python convention is exactly right for its other 
characteristics.  No declarations, no distinction.


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

Re: Odd ValueError using float

[emile]

On 03/14/2015 08:52 AM, Chris Angelico wrote:

On Sun, Mar 15, 2015 at 2:28 AM, emile  wrote:

It ran almost to completion before generating the error again --

(Pdb) decval
'4'
(Pdb) type(decval)

(Pdb) len(decval)
1
(Pdb) int(decval)
*** ValueError: invalid literal for int() with base 10: '41.703'

So there's still something amiss.


Compare these two lines' outputs:

print("str %d, int %d" % (id(str), id(int)))
print("str %d, int %d" % (id(type("")), id(type(0)))



(Pdb) print("str %d, int %d" % (id(str), id(int)))
str 505366496, int 505399904
(Pdb) print("str %d, int %d" % (id(type("")), id(type(0
str 505366496, int 505399904




Any difference in id would indicate that the names have been shadowed
- seems unlikely, but worth checking. And then, just to be absolutely
sure:

type(decval) is type("")


(Pdb) type(decval) is type("")
True



There is another, and very nasty, possibility. If you're working with
a C extension that has a refcount bug in it, all sorts of bizarre
things can happen - crucial type objects getting garbage collected,
objects getting disposed of and others taking their places, all kinds
of weird and wonderful things. Normally that'll eventually cause a
crash, but who knows...


Here're the imports:

import os, time, re, shutil, subprocess
from fenx.BBxXlate.bbxfile import BBxFile  # a pure python module
from fenx import RealPyOdbc2

and of course, pdb when I break for the error condition.

Emile

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

Re: generator/coroutine terminology

[Rustom Mody]

On Saturday, March 14, 2015 at 10:22:51 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Mar 15, 2015 at 3:33 AM, Rustom Mody wrote:
> > As best as I can see python makes no distinction between such a foo and
> > the more usual function/methods that have no returns.
> > You can I can talk about these and distinguish them
> > Python has no clue about it.
> 
> But what support is actually needed? Look, I can write functions that
> return values:
> 
> def square(x):
> return x*x
> 
> four = square(2)
> 
> and functions that don't:
> 
> def save_to_file(fn):
> with open(fn, "w") as f:
> f.write(stuff)
> f.write(more_stuff)
> 
> save_to_file("/tmp/asdf")
> 
> Who cares that the second one actually returns None and then ignores
> that? It's not returning anything, it's not using the function return
> value. This is, in effect, a procedure.
> 
> How is Python worse off for doing things this way rather than having a
> true "function with no return value" or "procedure" concept?

Well...
We can talk about that... maybe in another thread...
My more pressing question is that when I try to read the explanations of
generators, my tongue gets stuck behind my ears. And I suspect the problem is 
with the terminology

My original question was quite genuine:
Thanks to Marko's collections from the docs and also Steven's
> That glossary entry is misleading, or at least incomplete, and it fails to
> match the way "generator" is used by actual Python programmers. 

I guess I can confirm that the docs are messy the concepts are confused
and we (teachers) have to do whatever we will with that state of affairs.

[I admit to even having (tried to) teach C++. But I would not try to repeat that
feat if I had a choice]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Module/lib for controlling a terminal program using redrawing?

[Paul Rubin]

Dave Angel  writes:
>> Is there a module/library that can help me with this?
> https://docs.python.org/3/howto/curses.html

That's the opposite of what the OP wanted.  Curses generates the escape
codes and so on to draw your desired stuff on the terminal.  The OP
wants a screen scraper, something that takes the escape codes generated
by another program and interprets them to figure out what the screen is
supposed to look like.

The classic program that does this is Rog-o-matic.  I don't happen to
know of any Python code that does it but the search terms "python ansi
screen scraping" find some results that might be worth looking into.  It
also shouldn't be all that terribly hard to implement.

Leaving out the "ansi" keyword finds mostly HTML scrapers which aren't
what is wanted.  Trying other terminal types like "vt100" might find
desirable stuff though.
-- 
https://mail.python.org/mailman/listinfo/python-list

téléchaegement

[peronin jean jacques]

Bonjour

Je rencontre des problèmes d’ouverture de la console python . J’ai donc tout
désinstallé. Je vous demande donc qu’elle version je dois installer à partir
de votre site . J’utilise  Windows 8-1 sur PC portable.

Merci . Cordialement.

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

Re: Odd ValueError using float

[Peter Otten]

emile wrote:

> On 03/14/2015 09:08 AM, Peter Otten wrote:
>> emile wrote:
>>
>>> On 03/13/2015 08:09 PM, Chris Angelico wrote:
 On Sat, Mar 14, 2015 at 1:33 PM, Paul Rubin 
 wrote:
> emile  writes:
>> *** NameError: name 'val' is not defined
>> (Pdb) l
>> 139 try:
>> 140 val = round(float(decval),1)
>> 141 except:
>> 142 import pdb; pdb.set_trace()
>
> If 'float' or 'round' throw an exception, the assignment to 'val'
> never
> happens, so 'val' is undefined.  Try examining the value of 'decval'
> in the debugger to see what is making the conversion fail.

 That's exactly what the OP did :) Trouble is, it didn't help, because
 it sure looked as if decval was the string '4'. My best guess was -
 and is - that it's not just a string. We're looking at an SQL
 interface routine here, so it may be that there's a string subclass
 that length-limits itself, on the assumption that it's going into a
 fixed-length database field.
>>>
>>> It ran almost to completion before generating the error again --
>>>
>>> (Pdb) decval
>>> '4'
>>> (Pdb) type(decval)
>>> 
>>> (Pdb) len(decval)
>>> 1
>>> (Pdb) int(decval)
>>> *** ValueError: invalid literal for int() with base 10:
>>> '41.703'
>>>
>>> So there's still something amiss.
>>
>> Why are you checking
>>
>> int(decval)
> 
> 
> because it sure smells like int should work:
> 
> (Pdb) "3" True

That's a normal string comparison when decval is a string. This and the 
ValueError is expected Python behaviour:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> decval = "41.703"
>>> "3" < decval < "5"
True
>>> int(decval)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: '41.703'


>> when the actual failing expression is
>>
>> round(float(decval),1)
>>
>> ? Try to evaluate the latter in the debugger, and if that gives no clue
>> change
>>
>> 139 try:
>> 140 val = round(float(decval),1)
>> 141 except:
>> 142 import pdb; pdb.set_trace()
>>
>> to just
>>
>> val = round(float(decval), 1)
>>
>> to get a meaningful traceback and post that.
> 
> I don't get a traceback -- it spews:
> 
> Fatal Python error: deletion of interned string failed
> 
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> 
> then crashes and I get a Microsoft pop-up that says python.exe has
> encountered a problem and needs to close.

That does look bad. Most likely an extension written in C corrupts the 
interpreter or it's even a bug in the interpreter itself.

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

Re: téléchaegement

[Kev Dwyer]

peronin jean jacques wrote:

> Bonjour
> 
> Je rencontre des problèmes d’ouverture de la console python . J’ai donc
> tout désinstallé. Je vous demande donc qu’elle version je dois installer à
> partir
> de votre site . J’utilise  Windows 8-1 sur PC portable.
> 
> Merci . Cordialement.

Essayez pyt...@aful.org - python-list en francais si vous ne peut pas ecrire 
en anglais.

(et excusez ma francais pauvre, s'il vous plait)

Kev

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

Re: The idle gui

[Terry Reedy]

On 3/13/2015 4:58 PM, lmzent...@gmail.com wrote:

My python program was running for over six weeks.


This is not clear.  Do you mean that you wrote a program in python and 
that it ran continously, day and night, for 6 weeks?  Or that you 
successfully used python on and off for 6 weeks?  In either case, what 
version of python and what platform?



Then the idle gui stopped opening.


How are you trying to open Idle?  When happens when you try?  In any 
case, try opening from a command line with 'python -m idlelib' (or 
idlelib.idle on 2.7 or before).


> I have reinstalled several times but it doesn't work.

What does not work?  Python itself or just Idle?


Any idea?


One reason that Idle can stop working is that you (or something) made a 
bad configuration change.  The way to fix this is to find .idlerc in 
your home directory and empty it to remove the bad configuration.


Another possible reason is that you installed something or made a change 
to a system setting that interferes with Idle starting.


--
Terry Jan Reedy

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

Re: Module/lib for controlling a terminal program using redrawing?

[Terry Reedy]

On 3/14/2015 6:50 AM, Jason Heeris wrote:

I am trying to automate the use of some old, in-house terminal-based
programs that use screen redrawing for their interface. This includes
single line redrawing (eg. using '\r' and overwriting), complete screen
clearing, and fine-grained cursor movement and overwriting (probably not
all in the same program at the same time though).

Is there a module/library that can help me with this?

I know of pexpect, but that seems more oriented towards line-by-line
prompts that don't involve redraws (eg. login prompt, then password
prompt on a new line). Think instead of trying to automate applications
like emacs, aptitude or even nethack that redraw sections of the screen
without making the terminal scroll.

This automation requires more than just sending a set of keystrokes, but
also reading what is displayed on screen and making decisions based up
on that.

Is there a library that can abstract the received redrawing activity so
I don't have to even know if the application has, eg. used a carriage
return or some other kind of cursor movement? Is there a way to just ask
"if this were to be run in an ANSI terminal, what would be in each cell?"

Python 2 or 3 are both fine, external packages are fine, but it has to
work on Linux (eg. Ubuntu 14.04 or later, Debian Wheezy or later).

Any pointers appreciated.


Perhaps you can use the guts of a terminal emulation program, removing 
the part that displays the interpreted stream (a 24 x 80 array) on the 
screen.  Searching 'python terminal emulation' returns these


terminal.py - A Pure Python Terminal Emulator - GitHub Pages
liftoff.github.io/GateOne/Developer/terminal.html
This crux of this module is the Terminal class which is a pure-Python 
implementation of the quintessential Unix terminal emulator. It does its 
best to emulate an ...


pyte 0.4.9 : Python Package Index
https://pypi.python.org/pypi/pyte/
Python
Dec 3, 2014 - What is pyte? It's an in memory VTXXX-compatible terminal 
emulator. XXX stands for a series of video terminals, developed by DEC 
between ...


--
Terry Jan Reedy

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

Re: The idle gui

[Dave Angel]

On 03/14/2015 05:57 AM, Chris Angelico wrote:

On Sat, Mar 14, 2015 at 12:35 PM, Dave Angel  wrote:

Not if you don't take it to him.  If you just call him on the phone, and say
"Jimmy doesn't work" he doesn't even know what make and model the vehicle
is.  Or whether it's even a car.  Maybe "it" is a son who refuses to get a
job.


In the OP's defense, we were at least told that the "idle gui" was the
thing that didn't work. So unless you named your son "gui", we can
safely assume that this isn't the case :)



I wasn't actually trying to pick on the OP this time, but to make a 
joke.  Jimmy is the common nickname model of an SUV (truck/car), by 
General Motors. Idle could be taken two ways (if it weren't for the 
capitalization), or even three  (My Chevy won't idle.).


My father used to tell a triple pun involving the John Deere, and I 
can't recall it.


It's been said that puns are the lowest form of humor, but I rather like 
them.


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

Re: Pexpect idea - but can I handle curses?

[Thomas 'PointedEars' Lahn]

Skip Montanaro wrote:

> Let's just let this thread die, shall we? So far, nobody seems interested
> in attempting to answer my original question.

That might have to do with
, specifically
.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Odd ValueError using float

[emile]

On 03/14/2015 11:24 AM, Peter Otten wrote:

emile wrote:


On 03/14/2015 09:08 AM, Peter Otten wrote:



Why are you checking

int(decval)



because it sure smells like int should work:

(Pdb) "3"

That's a normal string comparison when decval is a string. This and the
ValueError is expected Python behaviour:



yes -- but i'd previously shown decval to have a length of 1, and how 
many things then fit that equation?





to get a meaningful traceback and post that.


I don't get a traceback -- it spews:

Fatal Python error: deletion of interned string failed

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

then crashes and I get a Microsoft pop-up that says python.exe has
encountered a problem and needs to close.


That does look bad. Most likely an extension written in C corrupts the
interpreter or it's even a bug in the interpreter itself.


I'm tight on time the rest of the day, but I think I'll next zap all the 
pyc versions, install a fresh 2.6.x python, and let it recompile.  About 
the only theory I have at the moment to explain the sudden failure after 
years of non-failure is disk based bit-rot.


Emile

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

Re: generator/coroutine terminology

[Ian Kelly]

On Sat, Mar 14, 2015 at 1:54 AM, Marko Rauhamaa  wrote:
> Steven D'Aprano :
>
>> Marko Rauhamaa wrote:
>>
>>> Your 'factory' is a:
>>>
>>> generator
>>> A function which returns an iterator.
>>> https://docs.python.org/3/glossary.html>
>>
>> That glossary entry is misleading, or at least incomplete, and it
>> fails to match the way "generator" is used by actual Python
>> programmers.
>
> I am an actual Python programmer (I develop Python programs) and my
> definitive source for Python is the documentation. If there is an error
> in the documentation, I would very much like it to be corrected.

I think that Steven was basing his statement on the definition you
cited. I don't think that he actually went and looked up the
definition. If he had, he would have seen that you omitted 90% of it.
Here's the full entry:

"""
A function which returns an iterator. It looks like a normal function
except that it contains yield statements for producing a series of
values usable in a for-loop or that can be retrieved one at a time
with the next() function. Each yield temporarily suspends processing,
remembering the location execution state (including local variables
and pending try-statements). When the generator resumes, it picks-up
where it left-off (in contrast to functions which start fresh on every
invocation).
"""

>> A generator (function) may be a function which returns an iterator,
>> but not all functions that return iterators are generators, and in
>> some ways returning an iterator is the *least* interesting part of
>> what makes a generator a generator.
>>
>> What distinguishes a generator from a regular function is the use of
>> `yield`. Any definition which fails to mention that fact is useless.

As can be seen above, the glossary definition *does* in fact discuss
the use of yield.

> The language reference had better use more precise language. It *is* the
> definitive source, after all.

Okay, but you cited the glossary entry, not the language reference.
The language reference says this [1]:

"When a generator function is called, it returns an iterator known as
a generator."

Which I think is quite clear, although to be fair the same section
also uses "generator" alone to refer to the function in the preceding
paragraph. That usage however is justified by PEP 255 [2]:

"""
When a generator function is called, the actual arguments are bound to
function-local formal argument names in the usual way, but no code in
the body of the function is executed.  Instead a generator-iterator
object is returned; this conforms to the iterator protocol, so in
particular can be used in for-loops in a natural way.  Note that when
the intent is clear from context, the unqualified name "generator" may
be used to refer either to a generator-function or a
generator-iterator.

"""

Now which should be considered definitive, the language reference or
the PEP? This question is not rhetorical; I don't know the answer.
Regardless of the answer though, the PEP at least illuminates the
design intent of the terminology.


[1] https://docs.python.org/3/reference/expressions.html#yield-expressions

[2] https://www.python.org/dev/peps/pep-0255/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: generator/coroutine terminology

[Mark Lawrence]

On 14/03/2015 20:14, Ian Kelly wrote:


Now which should be considered definitive, the language reference or
the PEP? This question is not rhetorical; I don't know the answer.
Regardless of the answer though, the PEP at least illuminates the
design intent of the terminology.



The language reference should be the definitive guide.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Micropython?

[jkn]

On Saturday, 14 March 2015 06:43:18 UTC, Paul Rubin  wrote:
> http://www.micropython.org/
> 
> Has anyone used this?  Know anything about it?  I don't remember seeing
> any mention of it here.  I remember there was a stripped down Python
> some years back that didn't work very well, but I think this is
> different.  I just came across it by accident.  Thanks.

I started a short thread on it last year; search for "FYI: Micro Python running 
on kickstarter pyBoard project, now shipping"

Our Tech Support department have a few of the boards and seem happy with them. 
I don't know much about what they are being used for though. I'd like to have 
the time...

   J^n
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pexpect idea - but can I handle curses?

[Cameron Simpson]

On 13Mar2015 10:17, Skip Montanaro  wrote:

I have this tweak I'd like to make to the top command (Linux only is fine).
[...] However... I have a feeling I might be fairly seriously
challenged trying to work with top's raw output, as it probably does
something more sophisticated than clear the screen and spit out rows. Will
I be in over my head trying to tweak the output? Hmmm... maybe if I tell
top TERM=dumb?


You may need to tell it TERM=dumb, though it might also refuse to run.

Like many full screen terminal apps, top is built on top of curses or ncurses; 
these libraries try to do minimal tty output, so they maintain an in memory 
image of the screen and only emit the terminal sequences requires to update 
changes. Much escape sequence parsing etc if you want to hack their output.


Now, if TERM-dumb is a no-go with top, another alternative is to write your own 
terminal definition (not trivial, but not too hard either as you don't need to 
implement all the operations, or even many of them: curses, given _sufficient_ 
capabilities, will figure it out). You might write an easy to parse terminal 
definition and run your own parser, and have _it_ output to python curses (with 
the correct $TERM on the output side).


But I suspect it might be just as easy to implement your own top by parsing 
stuff from /proc.


Your call...

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: generator/coroutine terminology

[Oscar Benjamin]

On 12 March 2015 at 16:52, Rustom Mody  wrote:
>
> On Thursday, March 12, 2015 at 9:58:07 PM UTC+5:30, Steven D'Aprano wrote:
>> Rustom Mody wrote:
>>
>> >
>> > Say I have a simple yielding function:
>> >
>> > def foo(x):
>> >yield x+1
>> >yield x+2
>> >
>> > And I have
>> >
>> > g = foo(2)
>> >
>> > If I look at type, g's type is 'generator' whereas foo is just plain-ol
>> > 'function.'
>> >
>> > Whereas in informal usage we say foo is a generator.
>>
>> Hopefully it is clear from context what we actually mean. When in doubt, we
>> should be explicit.
>
> There is a very important 'context' where both have to exist together -- 
> teaching beginners.

It is definitely important to draw the distinction between a generator
function and a generator in teaching. I would use distinct terminology
in any case. It's also important where possible to use the same
terminology as is used in the various different sources of
documentation that your students will encounter so inventing a new
term like "generator factory" is probably a bad idea.

> foo's are written to produce g's. g's come from foo-like.
>
> Better naming would help clarify -- your 'factory' is the best Ive seen so 
> far.

I dislike the term "generator factory". To me it suggests something
like foo below:

def baz():
yield 4

def bar():
yield 6
yield 7

def foo(x):
if x > 4:
return baz()
else:
return bar()

The existing terminology seems fine to me: A generator function is a
special kind of function containing a yield statement that always
returns a generator. A generator expression is a special kind of
expression that evaluates to a generator. A generator is a special
type of iterator that results from generator functions and generator
expressions.

> But the docs?!?! Hoo Boy My head spins trying to grok this
> https://docs.python.org/3/reference/expressions.html#generator-expressions
> And thats after being familiar with the origins of the idea in
> scheme/simula/CLU etc.

Perhaps the docs can be improved. I wouldn't recommend that particular
page to anyone who wasn't already familiar with the subject though.


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

Re: Odd ValueError using float

[Cameron Simpson]

On 14Mar2015 08:28, Emile van Sebille  wrote:

It ran almost to completion before generating the error again --

(Pdb) decval
'4'
(Pdb) type(decval)

(Pdb) len(decval)
1
(Pdb) int(decval)
*** ValueError: invalid literal for int() with base 10: '41.703'

So there's still something amiss.


Am I missing something obvious here? int() likes only ints, not floats:

   Python 2.7.9 (default, Dec 13 2014, 15:13:49)
   [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> int('1.3')
   Traceback (most recent call last):
 File "", line 1, in 
   ValueError: invalid literal for int() with base 10: '1.3'

   Python 3.4.3 (default, Feb 27 2015, 00:22:26)
   [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> int('1.3')
   Traceback (most recent call last):
 File "", line 1, in 
   ValueError: invalid literal for int() with base 10: '1.3'

Cheers,
Cameron Simpson 

C++ also supports the notion of *friends*: cooperative classes that are
permitted to see each other's private parts.
- Grady Booch, "Object Oriented Design with Applications"
--
https://mail.python.org/mailman/listinfo/python-list

Re: generator/coroutine terminology

[Marko Rauhamaa]

Oscar Benjamin :

> A generator is a special type of iterator that results from generator
> functions and generator expressions.

Is it necessary/useful for a Python application programmer to be
conscious of the different types of iterator? What mistaken usage could
arise if the application just treated all iterators as, well, iterators?


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

Re: Odd ValueError using float

[Chris Angelico]

On Sun, Mar 15, 2015 at 9:09 AM, Cameron Simpson  wrote:
> On 14Mar2015 08:28, Emile van Sebille  wrote:
>>
>> It ran almost to completion before generating the error again --
>>
>> (Pdb) decval
>> '4'
>> (Pdb) type(decval)
>> 
>> (Pdb) len(decval)
>> 1
>> (Pdb) int(decval)
>> *** ValueError: invalid literal for int() with base 10:
>> '41.703'
>>
>> So there's still something amiss.
>
>
> Am I missing something obvious here? int() likes only ints, not floats:

Possibly missing the bit where decval looks to be a string containing
the one character U+0034 DIGIT FOUR, and then suddenly has a whole
mess of extra characters. :)

Check out the fenx stuff, as that's the only non-stdlib code you have.
Maybe it calls on a C extension module somewhere deep inside it.

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

Re: generator/coroutine terminology

[Chris Angelico]

On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa  wrote:
> Oscar Benjamin :
>
>> A generator is a special type of iterator that results from generator
>> functions and generator expressions.
>
> Is it necessary/useful for a Python application programmer to be
> conscious of the different types of iterator? What mistaken usage could
> arise if the application just treated all iterators as, well, iterators?

If you treat them all as iterators, then you're safe, because that's
the lowest common denominator. But there are a number of other
iterators that have more features, including files, generators, etc.

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

Re: Module/lib for controlling a terminal program using redrawing?

[Jason Heeris]

Yes, Paul Rubin had it right: I hadn't thought of the term "screen
scraper," but that might help my searching.

On 15 March 2015 at 05:50, Terry Reedy  wrote:
>
> Perhaps you can use the guts of a terminal emulation program, removing
the part that displays the interpreted stream (a 24 x 80 array) on the
screen.  Searching 'python terminal emulation' returns these

Thanks for those results. I also discovered that someone wrote a Python
ANSI terminal scraper originally for use with Nethack:
https://github.com/helgefmi/ansiterm (although it seems generic enough).

Cheers,
Jason
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Micropython?

[Chris Angelico]

On Sat, Mar 14, 2015 at 5:43 PM, Paul Rubin  wrote:
> http://www.micropython.org/
>
> Has anyone used this?  Know anything about it?  I don't remember seeing
> any mention of it here.  I remember there was a stripped down Python
> some years back that didn't work very well, but I think this is
> different.  I just came across it by accident.  Thanks.

It's a rare thing: an alternative Python implementatin that targets
Py3 instead of Py2. I haven't been following the project lately
(largely because I don't use microcontrollers), but it's something
that should be encouraged, just on the basis of Python version.

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

Re: The idle gui

[Chris Angelico]

On Sun, Mar 15, 2015 at 12:04 AM, Dave Angel  wrote:
> I wasn't actually trying to pick on the OP this time, but to make a joke.
> Idle could be taken two ways (if it weren't for the capitalization), or even
> three  (My Chevy won't idle.).

Beware the Idles of March?

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

Re: generator/coroutine terminology

[Marko Rauhamaa]

Chris Angelico :

> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa  wrote:
>> Is it necessary/useful for a Python application programmer to be
>> conscious of the different types of iterator? What mistaken usage
>> could arise if the application just treated all iterators as, well,
>> iterators?
>
> If you treat them all as iterators, then you're safe, because that's
> the lowest common denominator. But there are a number of other
> iterators that have more features, including files, generators, etc.

What features do generator iterators provide on top of generic
iterators?


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

Re: generator/coroutine terminology

[Chris Angelico]

On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Sun, Mar 15, 2015 at 9:15 AM, Marko Rauhamaa  wrote:
>>> Is it necessary/useful for a Python application programmer to be
>>> conscious of the different types of iterator? What mistaken usage
>>> could arise if the application just treated all iterators as, well,
>>> iterators?
>>
>> If you treat them all as iterators, then you're safe, because that's
>> the lowest common denominator. But there are a number of other
>> iterators that have more features, including files, generators, etc.
>
> What features do generator iterators provide on top of generic
> iterators?

You can send values into them, throw exceptions into them, and close
them (which is a special case of the latter).

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

Re: generator/coroutine terminology

[Marko Rauhamaa]

Chris Angelico :

> On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa  wrote:
>> What features do generator iterators provide on top of generic
>> iterators?
>
> You can send values into them, throw exceptions into them, and close
> them (which is a special case of the latter).

Hm. I wonder why the distinction was made. IOW, why is

   iter([1, 2, 3])

not equivalent with

   (x for x in [1, 2, 3])

I can close the latter but not the former.

After all,

   yield from [1, 2, 3]

works all right.


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

Re: Pexpect idea - but can I handle curses?

[Skip Montanaro]

> That might have to do with
> , specifically
> .

Thanks, but not really helpful. I'm well aware of Eric Raymond's
contributions to the open source world. I'm also aware aware that my
question was not perfectly well-formed.

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

Re: Pexpect idea - but can I handle curses?

[Skip Montanaro]

>> Will I be in over my head trying to tweak the output? Hmmm... maybe if I
tell top TERM=dumb?
>
> You may need to tell it TERM=dumb, though it might also refuse to run.

It does run w/ TERM=dumb, so hopefully I won't have to resort to defining
my own terminal definition. (Now, *that* takes me back.) Now to see how
simple the output is...

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

Re: generator/coroutine terminology

[Chris Angelico]

On Sun, Mar 15, 2015 at 11:48 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Sun, Mar 15, 2015 at 11:15 AM, Marko Rauhamaa  wrote:
>>> What features do generator iterators provide on top of generic
>>> iterators?
>>
>> You can send values into them, throw exceptions into them, and close
>> them (which is a special case of the latter).
>
> Hm. I wonder why the distinction was made. IOW, why is
>
>iter([1, 2, 3])
>
> not equivalent with
>
>(x for x in [1, 2, 3])
>
> I can close the latter but not the former.

You don't need to close the former.

> After all,
>
>yield from [1, 2, 3]
>
> works all right.

That's using it as an iterable, which is not quite the same as an
iterator. (Iterators are themselves iterable; iter(x) is x, for any
iterator.) What you're doing there is roughly equivalent to:

for x in [1, 2, 3]:
yield x

but with a bunch of other simplifications and guarantees for edge
cases and things. So it's going to call iter() on what you give it.

If you treat things as iterators, you can use all sorts of things. You
don't need to distinguish the different types. The distinction is
important if you want to do more than just iterate over something.

>>> def gather():
lst = []
try:
  while True:
lst.append((yield len(lst)))
except StopIteration:
  yield lst

>>> n = gather()
>>> next(n)
0
>>> n.send("Hello")
1
>>> n.send("World")
2
>>> n.throw(StopIteration)
['Hello', 'World']

You can't do that with a simple iterator. (Not that I'm saying this is
good design...)

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

SQLObject 2.1.2 and 1.7.5

[Oleg Broytman]

Hello!

I'm pleased to announce versions 2.1.2 and 1.7.5, minor feature releases of
of SQLObject.


What's new in SQLObject
===

* Use fdb adapter for Firebird.

Contributor for this release is Neil Muller.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).

Python 2.6 or 2.7 is required.


Where is SQLObject
==

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/2.1.2
https://pypi.python.org/pypi/SQLObject/1.7.5

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: generator/coroutine terminology

[Rustom Mody]

On Sunday, March 15, 2015 at 1:45:37 AM UTC+5:30, Ian wrote:
> Now which should be considered definitive, the language reference or
> the PEP? This question is not rhetorical; I don't know the answer.
> Regardless of the answer though, the PEP at least illuminates the
> design intent of the terminology.
>  
>  
> [1] https://docs.python.org/3/reference/expressions.html#yield-expressions
>  
> [2] https://www.python.org/dev/peps/pep-0255/

Thanks

That PEP deserves careful reading, particularly the end...

| BDFL Pronouncements 
| Issue:  Introduce another new keyword (say, "gen" or "generator") in
| place of "def", or otherwise alter the syntax, to distinguish
| generator-functions from non-generator functions.
|  
| Con:  In practice (how you think about them), generators *are*
| functions, but with the twist that they're resumable.  The mechanics of
| how they're set up is a comparatively minor technical issue, and
| introducing a new keyword would unhelpfully overemphasize the
| mechanics of how generators get started (a vital but tiny part of a
| generator's life).
|  
| Pro:  In reality (how you think about them), generator-functions are
| actually factory functions that produce generator-iterators as if by
| magic.  In this respect they're radically different from non-generator
| functions, acting more like a constructor than a function, so reusing
| "def" is at best confusing.  A "yield" statement buried in the body is
| not enough warning that the semantics are so different.
|  
| BDFL:  "def" it stays.  No argument on either side is totally
| convincing, so I have consulted my language designer's intuition.  It
| tells me that the syntax proposed in the PEP is exactly right - not too
| hot, not too cold.  But, like the Oracle at Delphi in Greek mythology,
| it doesn't tell me why, so I don't have a rebuttal for the arguments
| against the PEP syntax.  The best I can come up with (apart from
| agreeing with the rebuttals ... already made) is "FUD".  If this had
| been part of the language from day one, I very much doubt it would have
| made Andrew Kuchling's "Python Warts" page.

So while I dont go to the extent of suggesting introducing a different keyword 
for
generators, the fact that the overloading of def is problematic and arbitrary
comes from the horse's (ie BDFL's) mouth.
-- 
https://mail.python.org/mailman/listinfo/python-list