Re: Need to 'import gtk' on Ubuntu 20.04, what do I need?

[Chris Green]

Akkana Peck  wrote:
> Chris Green writes:
> > I have recently upgraded my desktop system from ubuntu 19.10 to ubuntu
> > 20.04.  [ ... ]
> > The error I am getting is:-
> [ ... ]
> > ImportError: No module named gtk
> > 
> > So what do I need to install on my Ubuntu 20.04 system to provide the
> > gtk module?  
> 
> Ubuntu doesn't provide python-gtk any more at all. Which makes a
> number of programs rather difficult now ...
> 
Not quite true.  Originally this program failed with "ImportError: No
module named pygtk" so I fished around a bit (i.e. did some searches)
and installed python-gobject, python-gobject-2 and python-gi.  Doing
this got me past the "No module named pygtk", but I get the "No module
named gtk" still.  So Python GTK is sort of half available.


> > Alternatively (but much harder work) what is the Python 3 equivalent
> > of the the Python 2 pygtk and gtk modules.
> 
> ... because there is no close equivalent. In Python 3, GTK is
> accessed via something called GObject Introspection (module "gi")
> which requires significant changes to code beyond the usual 2to3
> Python migration.
> 
So is that what I'm getting by installing the things noted above.
I.e. 'import pygtk' is importing GObject things whereas 'import gtk'
is after the older stuff.

I'm a *fairly* competant Python programmer so, if I have to, I will
consider converting from using the gtk module to using the gi module,
are there any good tutorials which might help me down this road?


> You might be able to get the program working using pygtkcompat.
> Try inserting these lines near the beginning of the program:
> 
> from gi import pygtkcompat
> pygtkcompat.enable()
> pygtkcompat.enable_gtk(version='3.0')
> 
Ah, that sounds like it might be a reasonable path to try, I'll look
for documentation on pygtkcompat, it sounds as if that might be useful.


> If that doesn't work, you might be able to get the old Python 2/GTK 2
> packages working by installing these two files with dpkg -i.
> No warranty of safety or efficacy implied.
> 
> http://mirrors.kernel.org/ubuntu/pool/universe/p/pygtk/python-gtk2_2.24.0-6_amd64.deb
> http://mirrors.kernel.org/ubuntu/pool/universe/g/gimp/gimp-python_2.10.8-2_amd64.deb
> 
Yes, I found one thread on stackoverflow which went down this sort of
route but it's not going to be a long term solution I suspect.  I
think modernising and maintaining my own version of the code is going
to work better long term.


> Good luck! It was a nasty shock discovering that Ubuntu had removed
> python-gtk, especially since they kept lots of other python2 packages
> (I could have understood it if they'd removed python2 entirely).
> I don't know what the reasoning was for removing python-gtk while
> keeping python2.
> 
Yes, from my searches it seems to have bitten quite a few people.

Thanks for all the help.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Iterators, iterables and special objects

[Random832]

On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote:
> The transformers should be once-through iterators because they can be 
> passed once-through interators.  I suppose one could make them iterables 
> and add an attribute 'pristine' set to True in __init__ and False in 
> __iter__, but why have 2 objects instead of 1 when there is not gain in 
> function?

Why not just allow them to be iterated multiple times, and the underlying 
iterator/iterable either handles that or doesn't as the case may be? We don't 
have a hard API distinction between iterables and iterators, all iterators are 
"iterable" in the sense that they have their own __iter__ method that returns 
self.

i.e. the equivalent of

class map:
def __init__(self, func, obj): ...
def __iter__(self): for x in iter(self.obj): yield self.func(x)

That way if it is passed a once-through iterator, it is a once-through iterator 
with a couple extra steps, if passed an iterable it's an iterable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Iterators, iterables and special objects

[Chris Angelico]

On Sat, Jul 25, 2020 at 4:37 AM Random832  wrote:
>
> On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote:
> > The transformers should be once-through iterators because they can be
> > passed once-through interators.  I suppose one could make them iterables
> > and add an attribute 'pristine' set to True in __init__ and False in
> > __iter__, but why have 2 objects instead of 1 when there is not gain in
> > function?
>
> Why not just allow them to be iterated multiple times, and the underlying 
> iterator/iterable either handles that or doesn't as the case may be? We don't 
> have a hard API distinction between iterables and iterators, all iterators 
> are "iterable" in the sense that they have their own __iter__ method that 
> returns self.
>
> i.e. the equivalent of
>
> class map:
> def __init__(self, func, obj): ...
> def __iter__(self): for x in iter(self.obj): yield self.func(x)
>
> That way if it is passed a once-through iterator, it is a once-through 
> iterator with a couple extra steps, if passed an iterable it's an iterable.
>

And then someone will ask why you can't subscript a map object if the
underlying object could be subscripted, etc, etc, etc. It's not meant
to be a transparent layer over the object; it's just an iterator -
basically equivalent to:

def map(func, *iters):
try:
while True:
yield func(*(next(i) for i in iters))
except StopIteration:
pass

If you want a "MappedList" class, or a "MappedDict" class, or
whatever, then build it - it isn't hard.

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

Re: Iterators, iterables and special objects

[Random832]

On Thu, Jul 23, 2020, at 05:14, Peter Slížik wrote:
> > Works in what way? You can't use it in a 'for' loop if it doesn't
> > define __iter__.
> >
> 
> class Iterable:
> def __iter__(self):
> return Iterator(...)
> 
> class Iterator:
> def __next__(self):
> return 
> 
> # No __iter__ here.
> # I've just forgotten to def it.
> 
> With this setup, using for to iterate over Iterable *will* still work,
> though you cannot use the trick described below.

Sure, but you can't use for to iterate over _Iterator itself_, or do anything 
else useful with it.

>>> class Iterator:
...   def __init__(self): self.done=False
...   def __next__(self):
...if self.done: raise StopIteration
...self.done = True
...return 1
... 
>>> [*Iterator()]
>>> [*map(lambda x:x, Iterator())]
>>> [*filter(lambda x:True, Iterator())]
>>> for x in Iterator(): pass
...
>>> [x for x in Iterator()]
[all of the above have the exact same exception]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'Iterator' object is not iterable
>>> def gen():
...  yield from Iterator()
...
>>> [*gen()]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in gen
TypeError: 'Iterator' object is not iterable
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Iterators, iterables and special objects

[Random832]

On Fri, Jul 24, 2020, at 14:42, Chris Angelico wrote:
> And then someone will ask why you can't subscript a map object if the
> underlying object could be subscripted, etc, etc, etc. It's not meant
> to be a transparent layer over the object; it's just an iterator -
> basically equivalent to:
> 
> def map(func, *iters):
> try:
> while True:
> yield func(*(next(i) for i in iters))
> except StopIteration:
> pass
> 
> If you want a "MappedList" class, or a "MappedDict" class, or
> whatever, then build it - it isn't hard.

Asking to be able to restart the iteration is hardly the same thing as asking 
to pass through subscripts etc... C#'s Linq functions do fine with restartable 
iterables and hardly ever expose Iterators [well, IEnumerators, as they're 
called] to the user at all. If the original IEnumerable was restartable, so are 
all the intervening steps if you put an arbitrarily long chain of Select, 
Where, etc, on them, since each one restarts the one under it.

Obviously no-one should reasonably expect to be able to pass list subscripts 
through, say, a filter object, but restarting is a perfectly reasonable thing 
to do to *any* transformation of an iterable, whether or not it groups, splits, 
filters, interjects items or anything else you might imagine doing.
-- 
https://mail.python.org/mailman/listinfo/python-list

[SOLVED] Re: Installing Python 3.8.3 with tkinter

[Klaus Jantzen]

On 7/22/20 12:20 PM, Klaus Jantzen wrote:

Hi,

Trying to install Python 3.8.3 with tkinter I run configure with the 
following options


./configure --enable-optimizations --with-ssl-default-suites=openssl 
--with-openssl=/usr/local --enable-loadable-sqlite-extensions 
--with-pydebug --with-tcltk-libs='-L/opt/ActiveTcl-8.6/lib/tcl8.6' 
--with-tcltk-includes='-I/opt/ActiveTcl-8.6/include'


Running Python gives the following information

Python 3.8.3 (default, Jul 22 2020, 11:52:15)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> import tkinter
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.8/tkinter/__init__.py", line 36, in 

    import _tkinter # If this fails your Python may not be configured 
for Tk

ModuleNotFoundError: No module named '_tkinter'
>>>

Obviously there is something wrong with my configure options.

How do that correctly?

Thanks for any help.

K.D.J.



In my post I forgot to mention that I am running PY under Debian Buster.

As suggested by Ned Deily I switched to PY 3.8.5

After some more research in the internet I found that the tcl/tk 
libraries have automaticalle been installed during the Buster installation.


For automatically including tkinter during the PY installation one needs 
also the 'tk-dev toolkit'.


With that I did not need the options 
'--with-tcltk-libs'/'--with-tcltk-includes'


After the installation of PY 3.8.5 I can import tkinter.

Thank you very much for your replies.

K.D.J.



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

Re: Iterators, iterables and special objects

[dn via Python-list]

On 25/07/2020 06:35, Random832 wrote:

On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote:

The transformers should be once-through iterators because they can be
passed once-through interators.  I suppose one could make them iterables
and add an attribute 'pristine' set to True in __init__ and False in
__iter__, but why have 2 objects instead of 1 when there is not gain in
function?


Why not just allow them to be iterated multiple times, and the underlying 
iterator/iterable either handles that or doesn't as the case may be? We don't have a hard 
API distinction between iterables and iterators, all iterators are "iterable" 
in the sense that they have their own __iter__ method that returns self.

i.e. the equivalent of

class map:
 def __init__(self, func, obj): ...
 def __iter__(self): for x in iter(self.obj): yield self.func(x)

That way if it is passed a once-through iterator, it is a once-through iterator 
with a couple extra steps, if passed an iterable it's an iterable.



If the design calls for a single iteration of the contents of some 
container (for example), then need a signal to indicate 'end of data', 
ie StopIteration.


Conversely, if prepared to iterate continuously, don't ever want to see 
that exception.


How to differentiate?


Solution already available:
perhaps cycle() or chain()
itertools — Functions creating iterators for efficient looping
https://docs.python.org/3/library/itertools.html
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to limit *length* of PrettyPrinter

[Stavros Macrakis]

dn, Thanks again.

For background, I come from C and Lisp hacking (one of the MIT developers
of Macsyma /Maxima
) and also play with R, though
I haven't been a professional developer for many years. I know better than
to Reply to a Digest -- sorry about that, I was just being sloppy.

The reason I wanted print-length limitation was that I wanted to get an
overview of an object I'd created, which contains some very long lists. I
expected that this was standard functionality that I simply couldn't find
in the docs.

I'm familiar with writing pretty-printer ("grind") functions with string
output (from way back: see section II.I, p. 12
), but I'm
not at all familiar with Python's type/class system, which is why I'm
trying to understand it by playing with it.

I did try looking at the Python Standard Library docs, but I don't see
where it mentions the superclasses of the numerics or of the collection
types or the equivalent of *numberp*. If I use *type(4).__bases__*, I get
just* (,)*, which isn't very helpful. I suspect that that
isn't the correct way of finding a class's superclasses -- what is?

BTW, where do I look to understand the difference between *dir(type(4)) *(which
does not include *__bases__*) and *type(4).__dir__(type(4)) *(which does)?
According to Martelli (2017, p. 127), *dir(*x*)* just calls *x.**__dir__()*;
but *type(4).__dir__() *=> ERR for me. Has this changed since 3.5, or is
Martelli just wrong?

There's nothing else obvious in dir(0) or in dir(type(0)). After some
looking around, I find that the base classes are not built-in, but need to
be added with the *numbers* and *collections.abc *modules? That's a
surprise!

You suggested I try *pp.__builtins__.__dict__()* . I couldn't figure out
what you meant by *pp* here (the module name *pprint*? the class
*pprint.PrettyPrint*? the configured function
*pprint.PrettyPrinter(width=20,indent=3).pprint*? none worked...). I
finally figured out that you must have meant something like
*pp=pprint.PrettyPrinter(width=80).print;
pp(__builtins__.__dict__)*. Still not sure which attributes could be useful.

With bottom-up prototyping it is wise to start with the 'standard' cases!
(and to 'extend' one-bite at a time)


Agreed! I started with lists, but couldn't figure out how to extend that to
tuples and sets.  I was thinking I could build a list then convert it to a
tuple or set. The core recursive step looks something like this:

  CONVERT( map( lambda i: limit(i, length, depth-1) , obj[0:length] ) +
( [] if len(obj) <= length else ['...'] ) )

... since map returns an iterator, not a collection of the same type as its
input -- so how do I convert to the right result type (CONVERT)?

After discovering that typ.__new__(typ,obj) doesn't work for mutables, and
thrashing for a while, I tried this:

  def convert(typ,obj):
   newobj = typ.__new__(typ,obj)
   newobj.__init__(obj)
   return newobj

which is pretty ugly, because the *__new__* initializer is magically
ignored for a mutable (with no exception) and the *__init__* setter is
magically ignored for an immutable (with no exception). But it seems to
work

Now, on to dictionaries! Bizarrely, the *list()* of a dictionary, and its
iterator, return only the keys, not the key-value pairs. No problem! We'll
create yet another special case, and use *set.items()* (which for some
reason doesn't exist for other collection types). And *mirabile
dictu*, *convert
*works correctly for that!:

dicttype = type({'a':1})
test = {'a':1,'b':2}
convert(dicttype,test.items()) => {'a':1,'b':2}

So we're almost done. Now all we have to do is slice the result to the
desired length:

convert(dicttype,test.items()[0:1])  # ERR


But *dict.items() *is not sliceable. However, it *is* iterable... but we
need another count variable (or is there a better way?):


c = 0
convert(dicttype, [ i for i in test.items() if (c:=c+1)<2 ])


Phew! That was a lot of work, and I'm left with a bunch of special cases,
but it works. Now I need to understand from a Python guru what the Pythonic
way of doing this is which *doesn't* require all this ugliness.

(This doesn't really work for the original problem, because there's no way
of putting "..." at the end of a dictionary object, but I still think I
learned something about Python.)

I did take a look at the pprint source code, and could no doubt modify it
to handle print-length, but at this point, I'm still trying to understand
how Python code can be written generically. So I was disappointed to see
that *_print_list, _print_tuple, *and* _print_set *are not written
generically, but as three separate functions. I also wonder what the '({'
case is supposed to cover.

A lot of questions -- probably based on a lot of misunderstandings!

Thanks!

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