Re: How to create both a c extension and a pure python package
I was dealing with a very similar problem a long time ago. I wanted to provide built wheels of my Cython extension for various OSes (Windows, macOS, Linux) and various Python versions (from 2.7 up to 3.9) but I also wanted to have a sdist package for all the variations that I didn't cover at the time. What I ended up doing was automating the whole process on two different CI systems (one of those didn't have Windows support and the other was Windows-only) but also provided the sdist distribution with both Cython and Cython-generated C++ sources. Users can opt-in for cython installation using setuptools extras feature. For instance: pip install my-package[with-cython] Additionally whether to compile from Cython or C++ sources is controlled with environment variable, something like: CYTHONIZE=1 pip install my-package Using env vars instead of extra command arg for setup.py makes it easy to use with pip, poetry or whatever installer your user decides to use. The whole setup required a bit of work but in the end it has been working for a few years already. Definitely the hardest thing to maintain are those ever-changing CI systems. Adding the support for optional building from sources was actually the simplest to do. I don't spend a lot of time on the project lately but if you are interested how the whole thing was here's the url: https://github.com/swistakm/pyimgui śr., 10 mar 2021 o 20:57 Mats Wichmann napisał(a): > On 3/10/21 11:56 AM, Thomas Jollans wrote: > > On 10/03/2021 18:42, Marco Sulla wrote: > >> On Wed, 10 Mar 2021 at 16:45, Thomas Jollans wrote: > >>> Why are you doing this? > >>> > >>> If all you want is for it to be possible to install the package from > >>> source on a system that can't use the C part, you could just declare > >>> your extension modules optional > >> Because I want to provide (at least) two wheels: a wheel for linux > >> users with the C extension compiled and a generic wheel in pure python > >> as a fallback for any other architecture. > > > > What's wrong with sdist as a fallback rather than a wheel? > > > > That has the added benefit of people on other architectures have the > > opportunity to use the extension module if they have a compiler and the > > necessary libraries and headers installed... > > Doesn't that mean nasty failures for those don't have the correct build > setup (like almost every Windows user on the planet)? This isn't a > snide question, I'm actually interested in solving roughly the same > problem as the OP. > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: SSL/TLS certificate verification suddenly broken, Python 3 on Windows 10
I’ve had similar issue today on macOS when trying to download something from
PyPI with Python 3.9.1 but I didn’t try to debug it and just moved on to
different things. Maybe we both have outdated ca bundles?
Michał Jaworski
> Wiadomość napisana przez Carlos Andrews w dniu
> 16.02.2021, o godz. 16:42:
>
> Hi All,
>
> I ran into an error I, so far, cannot explain regarding Python's general
> ability to communicate via SSL/TLS.
>
> I'm using Python a lot to communicate with web servers and APIs, which
> worked just fine until yesterday (or somewhen late last week).
>
> I first noticed yesterday, when a requests-based call to a local web server
> with a self-signed certificate failed. No worries, I thought, passing the
> "verify=False" parameter to the request fixed the issue.
>
> Later on I used the same call to a public web server with a valid,
> CA-signed certificate and got the same error:
> SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
> certificate verify failed: unable to get local issuer certificate
> (_ssl.c:1123)'))
>
> That caused me to stop and try simple calls like
> import requests
> resp = requests.request('GET', 'https://www.nytimes.com/')
> to fail alike. And I surely would not turn off certificate verification to
> public websites.
>
> First assuming a network connection problem I tried curl, openssl or a web
> browser, all worked fine. Only Python fails.
>
> I checked the installed certificate bundle, all correct and even upgraded
> it to the latest version. No effect. I replaced it with the one curl is
> using and that curl managed to verify the cert with. No effect.
>
> By that time I was using a Python 3.7.9 installation on Windows 10 that ran
> fine for months (and also before upgrading to 3.7.9).
>
> I tried upgrading certifi and requests to the latest versions, which also
> caused the same SSLError, so I downloaded the wheel packages and forced a
> local upgrade - to no help.
>
> After that I deleted the whole Python installation directory and replaced
> it with a backup copy of a known-working version from a month ago. The
> error kept appearing.
>
> I then uninstalled Python completely, rebooted and installed Python 3.9.1,
> downloaded from python.org.
>
> The first to commands to issue were:
> C:\Users\Carlos>python -V
> Python 3.9.1
>
> C:\Users\Carlos>pip list
> PackageVersion
> -- ---
> pip20.2.3
> setuptools 49.2.1
> Could not fetch URL https://pypi.org/simple/pip/: There was a problem
> confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org',
> port=443): Max retries exceeded with url: /simple/pip/ (Caused by
> SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
> certificate verify failed: unable to get local issuer certificate
> (_ssl.c:1123)'))) - skipping
>
> So there went my theory of the requests module... It already happens with
> the Python base installation (urllib3?). Obviously a freshly installed
> Python with no modifications and no other modules installed fails to verify
> each and every certificate.
>
> I can rule out network errors as other machines using the same Internet
> breakout work just fine with the same code. And it happens using a web
> proxy and using no web proxy at all.
>
> Aunty Google always tells me to set "verify=False" but that can't be the
> solution for *this* problem. Unfortunately I have no idea where to look
> next - not with a fresh installation failing.
>
> Does anybody have a useful pointer for me? TIA!
>
> Regards,
> Carlos
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Sketch
Wow, that thread is entertaining. It seems that neos is one of it’s kind. What I hope is that it will support TempleOS. Going back going back to your original question Mr. Fibble. If ISO standard is what you really need to finish your project you can always take up this challenge and standardize the language yourself. From what I’ve learned already you have enough skills, experience and perseverance to complete such endeavor single-handedly. Michał Jaworski -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE tools to debug in Python?
PyCharm has all these debugging capabilities and there is a community edition that you can use for free. If you earn for the living with Python it is worth investing in professional edition though. Michał Jaworski > Wiadomość napisana przez flaskee via Python-list w > dniu 27.01.2021, o godz. 19:32: > > > While print() is groovy and all, > if anyone runs across a non-pdb python debugger (standalone or IDE-based) > please let me know. > > I too was blessed with IDE-based debugging (in the 90's!) > * where you can set break point(s); > * have the program stop right before a suspected failure point; > * check the contents of ALL variables, and choose whether to restart; > * or skip a few lines before restarting; > * or change a variable (hot, move back a few lines and restart, etc. > * Some, would even let you alter the code a bit before restarting. > > I too, miss this. > > > Hopefully I did not miss someone mentioning > such a python tool in the prior thread. > > Thanks! > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
> I think he's hinting at using a loop instead.
>
> while maritals != 'Yes' and maritals != 'No':
>maritals = input('Married: Yes/No ?: ').title()
Exactly. I would go even further and make it a reusable function. Eg.
def prompt_choices(prompt, choices):
choices = set(c.lower() for c in choices)
while value := input(f"{prompt} {choices}:").lower() not in choices:
pass
return value
Or without := operator:
def prompt_choices(prompt, choices):
value = None
choices = set(c.lower() for c in choices)
while value not in choices:
input(f"{prompt} {choices}:").lower()
return value
That way you can use it as follows:
marital = prompt_choices("Married", ["yes", "no"])
> So in other words I shoudn't nest functions like in
> changes(), add_people() etc but keep
> everything in one functions.
Simply move those functions outside of their "hosting" functions and
call them as they are. Also, many of them won't be needed anymore as you
introduce some generic helper functions (e.g. prompt_choices).
> Now I'll learn OOP as you said and then try to made this program again
> with OOP from scratch.
Recommend polishing the procedural approach a bit more too, though. Like
reducing code repetition. Looking into how data is stored, eg. can fields
be stored in CSV columns instead of JSON? OOP can be overwhelming at the
very beginning. For instance it can take some time learning what should be
an object and what shouldn't. You definitely can start adding e.g.
dataclasses because they are more like structures (e.g. struct in C
mentioned earlier).
czw., 17 gru 2020 o 17:38 Michael Torrie napisał(a):
> On 12/17/20 9:10 AM, Bischoop wrote:
> > Could you expand here, I rather don't know how I could do it different
> > way apart from if maritals == 'Yes' or maritals == 'No' or is it what
> > you meant?
>
> I think he's hinting at using a loop instead.
>
> while maritals != 'Yes' and maritals != 'No':
> maritals = input('Married: Yes/No ?: ').title()
>
> I think I got the logical condition right. Sometimes those are tricky!
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
I've made a quick look at the code and even executed it. It looks pretty
clear and is easy to understand, although it has some structural problems.
I won't do a thorough review but highlight the most important problems.
First, the recursive user input pattern you use:
def marriage():
maritals = input('Married: Yes/No ?: ').title()
while maritals != 'Yes' and maritals != 'No':
return marriage()
return maritals
It may look really convenient but you should really avoid that. In small
amounts it can be harmless, but it is kind of a resource leak. Aslo this
pattern is omnipresent so can quickly get out of hand and exceed maximum
recursion depth:
...
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
Fatal Python error: Cannot recover from stack overflow.
Current thread 0x000112836dc0 (most recent call first):
...
File "vimart.py", line 52 in menu_choice
File "vimart.py", line 52 in menu_choice
...
Abort trap: 6
Also, this choice-prompt pattern could be moved to a separate general
function so you don't have to repeat it all over the code. Take a look at
the prompt() function from click.termui module to get a better
understanding on how to build such things (
https://github.com/pallets/click/blob/master/src/click/termui.py). I would
also recommend creating helper functions for common things like displaying
results because right now it's hard to figure out which parts of
application constitute its presentation layer and which are part of "core
logic". Try to keep these two concepts separate and you will get better
results.
Second major structural "problem" are inline function definitions:
def add_people():
def how_old():
...
def p_sex():
...
def marriage():
...
You shouldn't be doing that unless you need a closure with nonlocal
variables to read from. Otherwise it really harms the readability. I
understand the urge to keep relevant code close to the usage but you would
have better results with modules. If you really want to keep everything in
a single module, keep functions close together in the file but don't nest
them. Use relevant naming conventions instead. Simply think of how you
would write that in C. You could use some object-oriented approach too, but
I would recommend polishing structural programming first.
There are also other issues like not always closing files, and not
validating the user input in specific places. Still, these will be more
evident as you improve the structure of application and do thorough
testing. Anyway, the code doesn't look bad. It of course needs improvement
but I've also seen worse specimens from people being actually paid for
writing the code.
Remember that "how to make things better" is a function of few parameters:
- what you want to achieve
- what are you able to do
- how much time do you have
If your sole goal is to learn and improve skills, I would recommend
polishing this in current procedural fashion to some extent, but not trying
to make it perfect. Then I would start from scratch and experiment with
different paradigms (OOP for instance). Then I would try to make a smaller
project that has some actual utility.
czw., 17 gru 2020 o 04:17 Bischoop napisał(a):
> On 2020-12-17, Bischoop wrote:
>
>
> Accidently removed the paste, https://bpa.st/E3FQ
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 2 to Python 3 .so library incompatibility - need help
I've looked into the details of the deb package that Cameron mentioned. It may be the one that you Chris uss because it does indeed include a pyscand.so file. Quick question to you Chris: the utilities you've mentioned are the code that you've written yourself or utilities from /usr/libexec/okimfputl that are shipped with the "driver package". In the deb package I've found following files: /usr/libexec/okimfputl/imgfilecv.py /usr/libexec/okimfputl/pushconfig.py /usr/libexec/okimfputl/pushass.py /usr/libexec/okimfputl/mfpcfgfile.py ... If that's the latter, I wouldn't even try to port that to Python 3. First, it would be clearly against the licence agreement. Second, that would probably result in total mess and take more time that it takes to earn for a new printer. If you really want to keep the printer (I wouldn't) I would do the following: upgrade your system, install Python 2.7 straight from sources in a separate location (e.g. /opt/oki-python?) and modify all shebang lines of the OKI python utilities from utilities to use that python location instead of "/usr/bin/env python" or "/usr/bin/python". That would make it totally independent of your system installation. The last thing would be probably installing pygtk in that "isolated" python installation as OKI utilities clearly rely on this. You could use venv for that or just simply make sure that gtk for python2 is in that python's library path. Whatever more convenient: you won't be using that python installation for anything else than supporting the driver. To be honest, what I would really do is to buy a new printer from a vendor that is known to be supporting their hardware for long term on the system you use. Printer vendors sucks. In the end, they always stop producing printing supplies you need and render your hardware useless. I have a combo that I can't refill with toner anymore which has used photoconductor drum that I can't replace anymore. I keep it around because it has a working scanner and haven't buyed a new printer because this one "almost works". Cheers, Michał śr., 16 gru 2020 o 23:48 Cameron Simpson napisał(a): > On 16Dec2020 21:59, Chris Green wrote: > >Cameron Simpson wrote: > >> On 16Dec2020 18:51, Chris Green wrote: > >> >The specific problem that finally prevented me from managing to get it > >> >to work was a (Linux) .so file that had been built for Python 2 and, > >> >as I don't have the source, I can't build for Python 3. > >> > >> ChrisA I think suggested keeping a Python 2.7 install around for this. > >> > >Not possible really as there are other python conflicts that start > >appearing if one tries to retain the libraries needed. > > Runtime python issues like you missing symbol error, or package conflict > issues? > > i.e. can you keep the OKI stuff sitting around along with Python 2 > install without having trouble with the PPA? > > >> >I need to have another go at fixing this as otherwise the code that > >> >I need to manage my printer will stop working as I update my Ubuntu > >> >systems. > > I'm leaning towards ChrisA's JSON suggestion at this point (absent newer > driver software). Keep a small Python 2 programme around which uses the > printer driver in whatever _basic_ ways you need, and _invoke that_ from > your modern Python 3 code as an external command, passing/receiving the > necessary information in JSON form as input.output, or on its command > line if that is more convenient. > > >> Have you considered keeping a legacy VM around as well? I have a few VMs > >> sitting here I use for some legacy software. > >> > >That's not a lot of use. The programs that I want to run (by > >converting to Python 3) are utility programs for my printer, they > >install with a handy 'app' in my toolbar. Having them in a VM > >wouldn't really do much good! :-) > > Fair enough. It seemed cumbersome to me too, but it is a viable way to > keep something legacy around, particularly if that legacy thing requires > a legacy OS. > > >I still have python 2. The issue is that the programs need modules > >which come from a PPA to support Python GTK, these conflict with > >ongoing updates to Python. The PPA works OK in Ubuntu 20.04 but > >prevents some updates in 20.10. I expect it will get worse as time > >goes on. > [...] > >> Guessing from the library name, have you looked on the OKI.com site > >> for current software? Maybe here? What's your printer model? > >> > https://www.oki.com/au/printing/support/drivers-and-utilities/index.html > >> > >> > >It comes from OKI with the Linux utilities for the printer, it's an > >MC342N. > > From here? > > > https://www.oki.com/uk/printing/support/drivers-and-utilities/colour-multifunction/01331401/?os=ab33=ac2 > > This driver? > > > https://www.oki.com/uk/printing/support/drivers-and-utilities/?id=46252701FZ01=drivers-and-utilities=colour-multifunction=01331401=ab33=ac2 > > I've just installed the .deb above on my Ubuntu 20.04.1 LTS system. > Aside from whinging about systemd it
