Re: pip unable to find an extension of a lib.

[Paul Moore]

>From https://pypi.org/project/PyQt5-sip/#files, it looks like the
project only distributes wheels (no source archive). You don't say
what platform you're using, but if it's Linux, the fact that you have
a debug Python probably means you need a different ABI, so the
standard wheels that they provide aren't compatible. So if there's no
compatible wheel and no source, there's nothing that can be installed.

pip install -v pyqt5 might give you some more information about why
the files available are not being considered as suitable, but I think
the above is likely.

Paul

On Fri, 12 Apr 2019 at 06:44, dieter  wrote:
>
> Vincent Vande Vyvre  writes:
> > ...
> > Using Python-3.7.2 (compiled with --with-pydebug) in a venv, I've
> > encountered this problem:
> >
> > $ pip install --upgrade pip setuptools wheel
> > 
> > Successfully installed setuptools-41.0.0 wheel-0.33.1
> > ---
> > ...
> > $ pip install pyqt5
> > ...
> > Collecting PyQt5_sip<4.20,>=4.19.14 (from pyqt5)
> >   Could not find a version that satisfies the requirement
> > PyQt5_sip<4.20,>=4.19.14 (from pyqt5) (from versions: )
> > No matching distribution found for PyQt5_sip<4.20,>=4.19.14 (from pyqt5)
> > ...
> > $ pip search pyqt5
> > ...
> > PyQt5-sip (4.19.15)   - Python extension module support
>
> There is a spelling difference: "PyQt5_sip" versus "PyQt5-sip" --
> not sure, however, whether this is important.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Adopting semantic versioning in trunk based development with Python

[dcs3spp via Python-list]

On Thursday, 11 April 2019 17:33:04 UTC+1, dcs3spp  wrote:
> Hi,
> 
> Hoping posting this in the correct place...Apologies if not
> 
> I am trying to understand how to use semantic versioning with trunk based 
> development for a Python project. Has anyone had any experience of adopting a 
> trunk based development with semantic versioning for packages?
> 
> I store the semantic version in version.py :__version__ which gets included 
> in setup.py
> 
> On the trunk (main) version.py:__version__ would be 1.0.0-SNAPSHOT and on the 
> CI server each build would append the build number, e.g. 1.0.0.1234-SNAPSHOT. 
> A changelog would initially be empty for the semantic version number on the 
> trunk (main).  
> 
> When ready to release a release branch would be created *release-1.0.x* and 
> any fixes, features would be cherry-picked from main. A gitlab CI job would 
> still run tests for commits on branches named *release-*. The release branch 
> may be tagged, e.g. 1.0.1, 1.0.2 etc. until the release stabilises. This 
> would bump the version number in version.py.
> 
> The changelog could be finalised on the release-branch, however this would 
> mean that it would have to be merged back to trunk(main). version.py would 
> also presumably have to be merged back to trunk after it is has been bumped 
> following hotfixes on the release branch. Is a merge from release to 
> trunk(main) acceptable in trunk based development for changelog and version 
> files only?
> 
> The problem would be if a new release, e.g. 1.1.0-SNAPSHOT was then prepared 
> for while release branch 1.0.x was still active then the version number would 
> be out of synch between trunk and release??
> 
> How is this managed with trunk based development approach?
> 
> Kind regards
> 
> dcs3spp

PS, error in my original question where I stated features cherry picked from 
main. Typo. Only fixes can be cherry picked from trunk(main) onto a release 
branch.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip unable to find an extension of a lib.

[Vincent Vande Vyvre]

Le 12/04/19 à 09:48, Paul Moore a écrit :

>From https://pypi.org/project/PyQt5-sip/#files, it looks like the
project only distributes wheels (no source archive). You don't say
what platform you're using, but if it's Linux, the fact that you have
a debug Python probably means you need a different ABI, so the
standard wheels that they provide aren't compatible. So if there's no
compatible wheel and no source, there's nothing that can be installed.

pip install -v pyqt5 might give you some more information about why
the files available are not being considered as suitable, but I think
the above is likely.

Paul


Exact, in mode verbose it enumerate all versions of pyqt-sip and all are declared 
"not compatible with this Python"

So I'll create a 3.7.3 venv without the "--with-pydebug"

Thanks,
Vincent.

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

Re: pip unable to find an extension of a lib.

[Vincent Vande Vyvre]

Le 12/04/19 à 07:40, dieter a écrit :

Vincent Vande Vyvre  writes:

...
Using Python-3.7.2 (compiled with --with-pydebug) in a venv, I've
encountered this problem:

$ pip install --upgrade pip setuptools wheel

Successfully installed setuptools-41.0.0 wheel-0.33.1
---
...
$ pip install pyqt5
...
Collecting PyQt5_sip<4.20,>=4.19.14 (from pyqt5)
   Could not find a version that satisfies the requirement
PyQt5_sip<4.20,>=4.19.14 (from pyqt5) (from versions: )
No matching distribution found for PyQt5_sip<4.20,>=4.19.14 (from pyqt5)
...
$ pip search pyqt5
...
PyQt5-sip (4.19.15)   - Python extension module support

There is a spelling difference: "PyQt5_sip" versus "PyQt5-sip" --
not sure, however, whether this is important.

Yes, I see that but the names returned by pip search are different than 
the names used with pip install


ie: PyQt5 versus pyqt5.


Vincent.

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

Tkinter performance issues between Windows and Linux

[Robert Okadar]

Hi community,

I have developed a tkinter GUI component, Python v3.7. It runs very well in
Linux but seeing a huge performance impact in Windows 10. While in Linux an
almost real-time performance is achieved, in Windows it is slow to an
unusable level.

The code is somewhat stripped down from the original, but the performance
difference is the same anyway. The columns can be resized by clicking on
the column border and dragging it. Resizing works only for the top row (but
it resizes the entire column).
In this demo, all bindings are avoided to exclude influence on the
component performance and thus not included. If you resize the window
(i.e., if you maximize it), you must call the function table.fit() from
IDLE shell.

Does anyone know where is this huge difference in performance coming from?
Can anything be done about it?

Thank you,
--
Robert Okadar
IT Consultant

Schedule an *online meeting * with
me!

Visit *aranea-mreze.hr*  or call
* +385 91 300 8887*

import tkinter

class Resizer(tkinter.Frame):
def __init__(self, info_grid, master, **cnf):
self.table_grid = info_grid
tkinter.Frame.__init__(self, master, **cnf)
self.bind('', self.resize_column)
self.bind('', self.resize_start)
self.bind('', self.resize_end)
self._resizing = False

self.bind('', self.onDestroyEvent)

def onDestroyEvent(self, event):
self.table_grid = []

def resize_column(self, event, width = None):
#if self._resizing:
top = self.table_grid.Top
grid = self.table_grid._grid
col = self.master.grid_info()["column"]
if not width:
width = self._width + event.x_root - self._x_root
top.columnconfigure(col, minsize = width)
grid.columnconfigure(col, minsize = width)


def resize_start(self, event):
top = self.table_grid.Top
self._resizing = True
self._x_root = event.x_root
col = self.master.grid_info()["column"]
self._width = top.grid_bbox(row = 0, column = col)[2]
#print event.__dict__

col = self.master.grid_info()["column"]
#print top.grid_bbox(row = 0, column = col)

def resize_end(self, event):
pass
#self.table_grid.xscrollcommand()
#self.table_grid.column_resize_callback(col, self)


class Table(tkinter.Frame):
def __init__(self, master, columns = 10, rows = 20, width = 100,**kw):
tkinter.Frame.__init__(self, master, **kw)
self.columns = []
self._width = width
self._grid = grid = tkinter.Frame(self, bg = "#CC")
self.Top = top = tkinter.Frame(self, bg = "#DD")
self.create_top(columns)
self.create_grid(rows)


#self.bind('', self.on_table_configure)
#self.bind('', self.on_table_map)

top.pack(anchor = 'nw')#, expand = 1, fill = "both")
grid.pack(anchor = 'nw')#fill = "both",expand = 1

def on_table_map(self, event):
theight = self.winfo_height()

def fit(self):#on_table_configure(self, event):
i = 0
for frame in self.Top.grid_slaves(row = 0):
frame.resizer.resize_column(None, width = frame.winfo_width())
i += 1
theight = self.winfo_height()
fheight = self._grid.winfo_height() + self.Top.winfo_height()
#print('', theight, fheight)
if theight > fheight:
rheight = self.grid_array[0][0].winfo_height()
ammount = int((-fheight + theight) / rheight)
#print(rheight, ammount)
for i in range(ammount):
self.add_row()
self.update()


def add_row(self, ammount = 1):
columnsw = self.columns
row = []
i = len(self.grid_array)
for j in range(len(columnsw)):
bg = self.bgcolor0
if i % 2 == 1:
bg = self.bgcolor1
entry = tkinter.Label(self._grid, bg = bg, text = '%i %i' % (i, j))
entry.grid(row = i, column = j, sticky = "we", padx = 2)
row.append(entry)
self.grid_array.append(row)


bgcolor0 = "#FF"
bgcolor1 = "#EE"
def create_grid(self, height):

#grid.grid(row = 0, column = 0, sticky = "nsew")

columnsw = self.columns# = self.Top.grid_slaves(row = 1)
self.grid_array = []
for i in range(height):
row = []
for j in range(len(columnsw)):
bg = self.bgcolor0
if i % 2 == 1:
bg = self.bgcolor1
#entry = self.EntryClass(False, self, self._grid, bg = bg, 
width = 1, )
entry = tkinter.Label(self._grid, bg = bg, text = '%i %i' % 
(i,j))
entry.grid(row = i, column = j, sticky = "we", padx = 2)
row.append(entry)
self.grid_ar