GUI: I am also looking for a nudge into the best (GUI) direction.
Hello! I've been reading the GUI toolkit posts. If anyone can give me a push in the right python direction on my needs, I'd be grateful. This is for business applications, not games. (but if a game toolkit fits...) I'm coming from Actionscript, where there is a lot of GUI flexibility. The Python toolkits that I've looked at feel mostly grid-oriented or zone-oriented (you can put the button on the left, or middle, or right, etc). I am 100% committed to using Python now; so I just want to see what toolkit(s)/pieces/frameworks will get me as much of the following as possible. What I'd like: * To target MacOS, Windows, Linux, Android using native widgets (this drops out Kivy). * To get the screen-size before loading anything else, and to resize controls & forms to have the same as aspect ratio across screen sizes. In actionscript you can say form.scale *= 1.5; and the form and ALL children resize appropriately with that one line. * To resize a control/widget and be able to easily move it later. Needed for the following point. * To handle portrait vs landscape rotation. I'm okay on the logic of resizing and repositioning controls accordingly [if the facility to do so exists]. * Touch events, like swiping, pinch-to-resize, etc. BeeWare (Toga) has some of this, but BeeWare seems "under-developed" and it is not even listed on any of the Python GUI comparison sites that I've seen. I just don't want to go too far down the wrong path, if you good folks can help. Right now I am plugging away on Gtk to see where that takes me. Thank you for your help in advance! Sent with [ProtonMail](https://protonmail.com) Secure Email. -- https://mail.python.org/mailman/listinfo/python-list
Module Download Problem
Hello!! I just download the latest version of python3 (Python3.9) and I have problem to download NumPy,… etc. Sent from [1]Mail for Windows 10 References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python extension module with callbacks into Python
> > Can you please clarify where/when I should call PyEval_InitThreads()? Is > > this in the main python thread before any pthread callbacks are generated? > > If so, should this be done only once? > Do it in your module init. That function is safe to be called multiple time. > I decided to do it in the extension module shared library initialization routine. It's guaranteed to be called when the shared library is loaded. > You could have answered the second part by reading the docs, which is what I > did to check what I was telling you. > My apologies. I realized that I should have read the manual first, but only after the impulse reaction to send the response. > Personally I do not code against the C api I use PyCXX to ease a lot of the > hardship of using the C api. See > http://cxx.sourceforge.net/PyCXX-Python3.html > Disclaimer I am the PyCXX maintainer. > > I have c++ classes to handle the Gil release and acquire that I use in pysvn > that you might find useful. > > See http://cxx.sourceforge.net/PyCXX-Python3.html and the > PythonAllowThreads PythonDisallowThreads classes that to the hard workin a > type safe way. > Thank you for that reference. I do not write a lot of python extension modules. However, when I do it again, I will seriously consider this as an option. -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
Hi, On Thu, Oct 29, 2020 at 1:05 PM Dennis Lee Bieber wrote: > > On Thu, 29 Oct 2020 15:54:33 +, flaskee via Python-list > declaimed the following: > > > > >What I'd like: > > > >* To target MacOS, Windows, Linux, Android using native widgets (this drops > >out Kivy). > > > That's going to knock out a lot of stuff. wxWidgets (base for > wxPython) > claims to use true "native widgets" on each supported OS (Android may > depend upon support for generic X-Window) https://www.wxwidgets.org/about/ This is not a claim - its reality. ;-) However Android will be a problem - it is not supported by the library, since its written in C++, and Android is JAVA-based. The best way is to learn "JAVAsucks" and write natively for Android. Thank you. > > > QT and GTK do not use the actual "native widgets" -- they instead have > styles/themes applied to their own widgets to make them look closer to the > OS native stuff, but may not behave quite the same. > > Tkinter is Tk-based, and doesn't look "native" on anything > > > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected]://wlfraed.microdiversity.freeddns.org/ > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
FW: Module Download Problem
Sorry I forgot: I have Windows10 Sent from [1]Mail for Windows 10 From: [2]Gian_Xatzak. Sent: Thursday, October 29, 2020 7:07 PM To: [3][email protected] Subject: Module Download Problem Hello!! I just download the latest version of python3 (Python3.9) and I have problem to download NumPy,… etc. Sent from [4]Mail for Windows 10 References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986 2. mailto:[email protected] 3. mailto:[email protected] 4. https://go.microsoft.com/fwlink/?LinkId=550986 -- https://mail.python.org/mailman/listinfo/python-list
Re: Module Download Problem
On 10/29/20 11:07 AM, Gian_Xatzak. wrote: >Hello!! > > > >I just download the latest version of python3 (Python3.9) and I have >problem to download NumPy,… etc. There are projects who have not released their 3.9-compatible wheels yet - the schedule for doing so is up to each of those projects. Check pypi for the packages that matter to you. For now, stick with Python 3.8. -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
On 29.10.2020 16:54, flaskee via Python-list wrote: Thank you for your help in advance! Maybe, you should outline what you actually want to accomplish on each platform group (desktop / mobile). Regards, Dietmar -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
Hi, On Thu, Oct 29, 2020 at 11:33 AM flaskee via Python-list wrote: > > Hello! > > I've been reading the GUI toolkit posts. > > If anyone can give me a push in the right python direction on > my needs, I'd be grateful. > > This is for business applications, not games. > (but if a game toolkit fits...) > > I'm coming from Actionscript, > where there is a lot of GUI flexibility. > > The Python toolkits that I've looked at feel mostly grid-oriented > or zone-oriented (you can put the button on the left, or middle, > or right, etc). I don't think it is easily possible in a cross-platform environment. But even if your software is one platform only how will you handle DPI change, theme change and other system changes? You will have to have some kind of layout system. > > I am 100% committed to using Python now; > so I just want to see what toolkit(s)/pieces/frameworks > will get me as much of the following as possible. > > What I'd like: > > * To target MacOS, Windows, Linux, Android using native widgets (this drops > out Kivy). See my previous reply. > > * To get the screen-size before loading anything else, and to resize controls > & forms to have the same as aspect ratio across screen sizes. In actionscript > you can say form.scale *= 1.5; and the form and ALL children resize > appropriately with that one line. You are overthinking it. What if the window will be positioned on half normal DPI screen and half on HighDPI one? Or there was a theme change with the start of your software? As I said you absolutely have to have some kind of layout system or end up having 100 copies of same window prepared for a different layouts. Just accept that there are different layouts available for you that will handle every possible situation. > > * To resize a control/widget and be able to easily move it later. Needed for > the following point. > > * To handle portrait vs landscape rotation. > I'm okay on the logic of resizing and repositioning controls accordingly [if > the facility to do so exists]. You mean positioning controls on the screen with portrait vs landscape? Or during printing? Please clarify. > > * Touch events, like swiping, pinch-to-resize, etc. > > BeeWare (Toga) has some of this, but BeeWare seems "under-developed" and > it is not even listed on any of the Python GUI comparison sites > that I've seen. > > I just don't want to go too far down the wrong path, if you good folks can > help. > > Right now I am plugging away on Gtk to see where that takes me. As being said GTK does not use native widgets. > > Thank you for your help in advance! If you have any further questions you can contact me directly. Thank you. > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
> The Python toolkits that I've looked at feel mostly grid-oriented > or zone-oriented (you can put the button on the left, or middle, > or right, etc). I don't think it is easily possible in a cross-platform environment. But even if your software is one platform only how will you handle DPI change, theme change and other system changes? You will have to have some kind of layout system. - Thanks Igor. I'm actually converting a large actionscript set of apps, that already had Android/iOS, Windows app, Mac app and Browser versions; and that all shared about 80% of the self-written, layout code. Works great -- resizes between mobile device sizes automatically, scales widgets to fit, rotates portrait to landscape, all of that. But it had Very poor Linux support. I want to rebuild for all of these platforms, plus Linux. Really, MOSTLY, for Linux. And I really want Python as the new core for most things. Thanks Sent with [ProtonMail](https://protonmail.com) Secure Email. -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
On 10/29/20 11:30 AM, Igor Korot wrote: If you have any further questions you can contact me directly. Please do not. By keeping the discussion on the list many people can participate and learn. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
Hi, Ethan,
On Thu, Oct 29, 2020 at 6:51 PM Ethan Furman wrote:
>
> On 10/29/20 11:30 AM, Igor Korot wrote:
>
> > If you have any further questions you can contact me directly.
>
> Please do not. By keeping the discussion on the list many people can
> participate and learn.
If the OP has further questions about wx{Widgets, Python, Phoenix}
(s)he can send me direct e-mail.
But of course if it's related to python itself I'd forward it to the ML.
Thank you.
>
> --
> ~Ethan~
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Question on ABC classes
On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer wrote: > On 2020-10-22 23:35:21 -0700, Julio Di Egidio wrote: > > On Friday, 23 October 2020 07:36:39 UTC+2, Greg Ewing wrote: > > > On 23/10/20 2:13 pm, Julio Di Egidio wrote: > > > > I am now thinking whether I could achieve the "standard" > > > > behaviour via another approach, say with decorators, somehow > > > > intercepting calls to __new__... maybe. > > > > > > I'm inclined to step back and ask -- why do you care about this? > > > > > > Would it actually do any harm if someone instantiated your > > > base class? If not, then it's probably not worth going out > > > of your way to prevent it. > > > > This is the first little library I try to put together > > in Python, and it was natural for me to hit it with all > > the relevant decorations as well as type annotations in > > order to expose *strict* contracts, plus hopefully have > > intellisense work all over the place. > > I think you are trying to use Python in a way contrary to its nature. > Python is a dynamically typed language. Its variables don't have types, > only its objects. And basically everything can be changed at runtime ... Consider this example: def abs(x): return math.sqrt(x.re**2 + x.im**2) That of course fails if we pass an object not of the correct (duck) type. But the exception is raised by math.sqrt, which, properly speaking, beside considerations on usability, is a private detail of the implementation of abs. The point is more about what the function semantically represents and to which point the implementation fulfils that promise/contract. What is that "abs" really supposed to provide? Let's say: << 'abs', given a "complex number" (duck-typed or not), returns its "real number" magnitude >>. And that's it, not just the doc but really what *type* of computation it is, and then the mathematics we can apply to types. And an effect is that, by constraining the domains (and codomains) of functions, we make verification of correctness, the need for defensive coding, as well as for plain testing, less onerous by orders of magnitude. So, at least for a function in a public interface, we *must* add validation (and the doc string): def abs(x): """...as above...""" if not isinstance(x, ComplexNumber): raise TypeError(...) return math.sqrt(x.re**2 + x.im**2) and then why not rather write: @typechecked def abs(x: ComplexNumber) -> RealNumber: return math.sqrt(x.re**2 + x.im**2) i.e. checked by the tools statically and/or at runtime, with, for easy intellisense, the default doc string that comes from the signature? More generally, I do think dynamic typing leads to interesting patterns of reuse, but I think "unconstrained" is a red herring: ab initio there is a *requirement* to fulfil. > It now has type annotations, but they are ignored both by the compiler > and at run-time. They are only for the benefit of linting tools like > mypy and editor features like intellisense. For the chronicle, I have meanwhile switched from pylint to mypy (in VSCode) and things have improved dramatically, from configurability to intellisense to static type checking working pretty well. I have meanwhile also realised that the built-in solutions (the typing module and so on) as well as the tools supporting them (including those for runtime validation) are still quite young, so instead of venting frustration (and I must say so far I think the typing module is a mess), as I have done in the OP, I should be patient, rather possibly give a hand... > > and the whole lot, indeed why even subclass ABC? > > Good question. In six years of programming Python, I've never used ABC. > But then I came from another dynamically typed language to Python. Back in the day we had a laugh when intellisense was invented... but now, with the eco-info-system booming with everything and the contrary of everything (to put it charitably), I think it's about (formal, as much as possible) verifiability and correctness. Anyway. my 2c. Sorry for the long post and thanks for the feedback. Julio -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI: I am also looking for a nudge into the best (GUI) direction.
On Thu, Oct 29, 2020 at 4:48 PM Ethan Furman wrote: > On 10/29/20 11:30 AM, Igor Korot wrote: > > > If you have any further questions you can contact me directly. > > Please do not. By keeping the discussion on the list many people can > participate and learn. > This list isn't terribly overnoisy. But sun-managers had a terrific signal/noise ratio back in the day, by asking OP's to receive messages off list, and sending a self-composed summary of the replies back to the list. -- https://mail.python.org/mailman/listinfo/python-list
Re: Question on ABC classes
On Fri, Oct 30, 2020 at 1:06 PM Julio Di Egidio wrote: > > On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer wrote: > > I think you are trying to use Python in a way contrary to its nature. > > Python is a dynamically typed language. Its variables don't have types, > > only its objects. And basically everything can be changed at runtime ... > > Consider this example: > > def abs(x): > return math.sqrt(x.re**2 + x.im**2) > > That of course fails if we pass an object not of the correct > (duck) type. But the exception is raised by math.sqrt, which, > properly speaking, beside considerations on usability, is a > private detail of the implementation of abs. Not sure what sorts of errors you're expecting, but for the most part, if it's not a complex number, you should get an AttributeError before you get into the sqrt. (Although I'm not sure why you're looking for ".re" and ".im" - typo? Python's complex type has ".real" and ".imag", and you can accept any numeric type that way - even fractions.Fraction.) It's highly unlikely that you'd have real and imaginary parts that can be squared and summed, but the result can't be squirted. But here's the thing: even if that IS the case, most Python programmers are fine with getting an AttributeError stating exactly what the problem is, rather than a TypeError complaining that it has to be the exact type some other programmer intended. A good example is dictionaries and dict-like objects; if your code type checks for a dict, I have to give you a dict, but if you just try to do whichever operations you need, I can create something more dynamic and give you that instead. Python doesn't push for heavy type checking because it's almost certainly not necessary in the majority of cases. Just use the thing as you expect it to be, and if there's a problem, your caller can handle it. That's why we have call stacks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Question on ABC classes
On Friday, 30 October 2020 05:09:34 UTC+1, Chris Angelico wrote: > On Fri, Oct 30, 2020 at 1:06 PM Julio Di Egidio wrote: > > On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer wrote: > > > I think you are trying to use Python in a way contrary to its nature. > > > Python is a dynamically typed language. Its variables don't have types, > > > only its objects. And basically everything can be changed at runtime ... > > > > Consider this example: > > > > def abs(x): > > return math.sqrt(x.re**2 + x.im**2) > > > > That of course fails if we pass an object not of the correct > > (duck) type. But the exception is raised by math.sqrt, which, > > properly speaking, beside considerations on usability, is a > > private detail of the implementation of abs. > > Not sure what sorts of errors you're expecting, but for the most part, > if it's not a complex number, you should get an AttributeError before > you get into the sqrt. Yes, sorry, I was glossing over an example that was meant to be just general. I could have written something like: def abs(x): ...bunch of possibly complex operations... and that that is completely opaque both to the user of the function as well as, in my opinion, to its author (code must speak to speak for itself!). Not to mention, from the point of view of formal verification, this is the corresponding annotated version, and it is in fact worse than useless: def abs(x: Any) -> Any: ...some code here... Useless as in plain incorrect: functions written in a totally unconstrained style are rather pretty much guaranteed not to accept arbitrary input... and, what's really worse, to be unsound on part of the input that they do accept: read undefined behaviour. > But here's the thing: even if that IS the case, most Python > programmers are fine with getting an AttributeError stating exactly > what the problem is, rather than a TypeError complaining that it has > to be the exact type some other programmer intended. A good example is > dictionaries and dict-like objects; if your code type checks for a > dict, I have to give you a dict, but if you just try to do whichever > operations you need, I can create something more dynamic and give you > that instead. I did say "duck-typing or not". I was not talking of restricting dynamism (python protocols are an implementation of duck typing and can be used in typing annotations, even generic protocols), the point is making intentions explicit: to the benefit of the user of that code, but also to that of the author, as even the author has to have some "plan" in mind. As well as, eventually, to the various tools and checkers. > Python doesn't push for heavy type checking because it's almost > certainly not necessary in the majority of cases. Just use the thing > as you expect it to be, and if there's a problem, your caller can > handle it. That's why we have call stacks. I am learning Pandas and I can rather assure you that it is an absolute pain as well as loss of productivity that, whenever I misuse a function (in spite of reading the docs), I indeed get a massive stack trace down to the private core, and have to figure out, sometimes by looking at the source code, what I actually did wrong and what I should do instead. To the point that, since I want to become a proficient user, I am ending up reverse engineering the whole thing... Now, as I said up-thread, I am not complaining as the whole ecosystem is pretty young, but here the point is: "by my book" that code is simply called not production level. Julio -- https://mail.python.org/mailman/listinfo/python-list
Re: Question on ABC classes
On Fri, Oct 30, 2020 at 5:16 PM Julio Di Egidio wrote: > Not to mention, from the point of view of formal verification, > this is the corresponding annotated version, and it is in fact > worse than useless: > > def abs(x: Any) -> Any: > ...some code here... > Useless because, in the absence of annotations or other information saying otherwise, "Any" is exactly what you'd get. There's no point whatsoever in annotating that it ... is exactly what it would be without annotations. Unless you're trying for some sort of rule "all functions must be annotated", or something, it's best to just not bother. > Useless as in plain incorrect: functions written in a totally > unconstrained style are rather pretty much guaranteed not to > accept arbitrary input... and, what's really worse, to be > unsound on part of the input that they do accept: read > undefined behaviour. Not quite true. You're assuming that the annotation is the only thing which determines what a function will accept. Consider that the function had been written thus: def abs(x): """Calculate the magnitude of a (possibly complex) number""" return (x.real ** 2 + x.imag ** 2) ** 0.5 The docstring clearly states that it expects a number. But ANY number will do, so long as it has .real and .imag attributes. Python's core types all have those; the numpy int, float, and complex types all have those; any well-behaved numerical type in Python will have these attributes. In fact, if you were to annotate this as "x: numbers.Complex", it would give exactly zero more information. This function requires a number with real and imag attributes - that's all. If anything, such an annotation would confuse people into thinking that it *has* to receive a complex number, which isn't true. There is nothing undefined here. If you give it (say) a string, you get a nice easy AttributeError saying that it needs to have a .real attribute. > > Python doesn't push for heavy type checking because it's almost > > certainly not necessary in the majority of cases. Just use the thing > > as you expect it to be, and if there's a problem, your caller can > > handle it. That's why we have call stacks. > > I am learning Pandas and I can rather assure you that it is an > absolute pain as well as loss of productivity that, whenever I > misuse a function (in spite of reading the docs), I indeed get > a massive stack trace down to the private core, and have to > figure out, sometimes by looking at the source code, what I > actually did wrong and what I should do instead. To the point > that, since I want to become a proficient user, I am ending up > reverse engineering the whole thing... Now, as I said up-thread, > I am not complaining as the whole ecosystem is pretty young, > but here the point is: "by my book" that code is simply called > not production level. > Part of the art of reading exception tracebacks rapidly is locating which part is in your code and which part is library code. Most of the time, the bug is at the boundary between those two. There are tools that can help you with this, or you can develop the skill of quickly eyeballing a raw traceback and finding the part that's relevant to you. I don't think this is a consequence of the ecosystem being young (Pandas has been around for twelve years now, according to Wikipedia), but more that the Python community doesn't like to destroy good debugging information and the ability to fully duck-type. Solve the correct problem. If tracebacks are too hard to read, solve the traceback problem, don't try to force everything through type checks. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
