DelphiVCL4Python

[limelect 48]

Am I the only one toying with this?

Made a  simple form

got  project and unit PY

now to my point

in unit we have

class Form1(Form):

    def __init__(self, owner):
        self.Label1 = None
        self.label2 = None

and so on

if I delete file Unit1.pydfm    (which mean that this file is the form shown) the form is empty

OK so whats the point for the source in  unit PY as it really does nothing.

So my main question is how do I use label or button or any component  INSIDE Unit1.pydfm

otherwise the nice idea is useless

 

I have read the book Getting Started with Python GUI Development.pdf

it does not refer to PYDFM 

if I change self.Label1 = None to 

self.Label1 = Label(self)

self.Label1 .SetProps( Parent=self, Caption="Hello DelphiVCL for Python")

 It adds a label but does not change my label on pydfm

Who can help?????

 

P.S the book is not different then Tkinter

Edited June 23 by limelect

[pyscripter 689]

You are posting on the General Help forum.  Since your topic is related to P4D you will get a better response by posting such questions to the Python4Delphi forum.

 

The pydfm file plays the role of the dfm file in delphi.   The statement 

self.LoadProps(os.path.join(os.path.dirname(os.path.abspath(__file__)), "MainForm.pydfm"))

creates the controls and loads the design properties.

 

Have a look at the demo DelphiVCL4Python/samples/DesignExport/SampleForm/MainForm.py at main · Embarcadero/DelphiVCL4Python (github.com)

 

After the call to LoadProps, you can modify the controls.   For example:

 

        self.LoadProps(os.path.join(os.path.dirname(os.path.abspath(__file__)), "MainForm.pydfm"))
        self.Button1.Caption = 'New Caption'

 

Will show Button1 with Caption = 'New Caption'

 

 

You can assign python code to events (e.g  self.Button1.OnClick  = ) or customize the controls in any way you wish.

Edited June 23 by pyscripter

[hsauro 40]

8 hours ago, limelect said:

I’ve used and it seems to work ok. I think it’s a nice idea. I only encountered one minor edge case (can’t remember them now) but the developers quickly fixed the issue.

[limelect 48]

19 hours ago, pyscripter said:

After the call to LoadProps, you can modify the controls.   For example:

 

This small important detail was never mentioned anywhere

thanks

Edited June 24 by limelect

[limelect 48]

Just to see if I understood I made this Python package tester/ installer

in an hour not bad for a Delphi professional

Thanks

 

import os

import importlib.util

import sys
 

from delphivcl import *

 

class Form1(Form😞
 

    def __init__(self, owner😞

        self.Label1 = None

        self.Label2 = None

        self.LabeledEdit1 = None

        self.Button1 = None

        self.LoadProps(os.path.join(os.path.dirname(os.path.abspath(__file__)), "Unit1.pydfm"))

        self.Label2.caption=""

        self.button1.SetProps(Parent=self, Caption="Add", OnClick=self.Button1Click)
 

    def Button1Click(self, Sender😞

        self.Label2.caption=""

        name = self.LabeledEdit1.text  #    'itertools'
 

        if name != "":
 

            if name in sys.modules:

             self.Label2.caption=f"{name!r} already in sys.modules"

            elif (spec := importlib.util.find_spec(name)) is not None:

    # If you choose to perform the actual import ...

                 module = importlib.util.module_from_spec(spec)

                 sys.modules[name] = module
                 spec.loader.exec_module(module)

                 self.Label2.caption=f"{name!r} has been imported"

            else:

                 self.Label2.caption=f"can't find the {name!r} module"
 

    def FormCreate(self, Sender😞

        pass

 

[pyscripter 689]

3 hours ago, limelect said:

 self.button1.SetProps(Parent=self, Caption="Add", OnClick=self.Button1Click)

You don't need Parent = self.  Otherwise that's the idea.

[limelect 48]

Thanks.

In any case, I do not see myself using Python although everybody

is bragging about.

This is the same reason that the Basic language is gone. Interpreter.

I wanted to see what I could do with it.

 

P.S I made an execution of it and cannot find the Delphi lib but that is another matter

     I am using Anaconda

Edited June 25 by limelect

[David Heffernan 2345]

2 hours ago, limelect said:

This is the same reason that the Basic language is gone. Interpreter.

For loads of scenarios the interpreter doesn't matter for performance. 

[shineworld 73]

You can greatly improve the speed of a python script
by passing it through Cython and obtaining compiled pyd (windows dll) or .so (linux library) output modules that can then be imported without any modification into the original code.

I use Cython a lot.
At the end of a project, through a script, I "cython" all the .py modules to get a version
more performant and difficult to reverse engineer.

In the middle Cython convert .py to .c and compile to pyd using MSCV or any other C++ compiler.

Edited June 25 by shineworld

[pyscripter 689]

I have used Python for many many years and really like the language.   However it is slow.  Really slow.  And it does not use those damn CPU cores in my computer.

If you look at Python (created in 1989) and Ruby (created in 1993), they have a lot in common and the same limitations.  Ruby is also quite nice and there was a lot of buzz around it about 10-15 years ago, but the slowness almost killed the interest in the language.  On the other hand, and in a hard to explain way, Python flourished. In an irreversible way.  It is now the main programming language in schools and universities, including computer science degrees.   It is here to stay for many years to come.

 

Of course you can make python faster (Cython, using optimized python extension modules, multiprocessing etc.), but it takes an effort.

 

The focus of python development has been two areas:

• type safety (kind of odd for a dynamic language)
• execution speed

The two at some point may converge.  There are a few developments regarding speed that offer some hope;

• Per interpreter Gil introduced in Python 12 (see https://en.delphipraxis.net/topic/10372-true-thread-parallelism-with-p4d-and-python-12).  This is only accessible in embedded Python, using the python API. There were proposals to make it accessible through the interpreter, but were rejected in favour of the following developments.

• Experimental Just-in-Time (JIT) Compilation introduced in the coming Python 3.13 (so far, the speed improvements are negligible)

• Free threaded python (GIL-free) also introduced in python 3.13.  Sounds good but it is incompatible with the GIL-enabled version of python.   Extension modules are also incompatible and the two versions will be available in parallel, which sounds messy.

 

Edited June 25 by pyscripter

[David Heffernan 2345]

The scenarios I'm thinking of are numerical programming where the bottlenecks are migrated to math libs like openblas

[shineworld 73]

Everything described by pyscripter is pure truth.
I came to Python because of the need to use OpenCV with Delphi in analyzing frames from camera.
There are a couple of wrapper libraries for OpenCV, but when I tried them they were more pains than joys.
I then learned about DelphiVCL for python and that fixed the damaging issue of a good UI in Python.
The whole phase of capturing frames from IP camera via Python was a bloodbath, too slow and blocking, even using in threads that are not parallel anyway.
But Python4Delphi gave me the ability to "move" the heavy, parallel processing into Delphi threads.
So I moved the camera communication and frame retrieval into a Delphi class using threads and Indy then exported to Python with P4D, quietly getting the required 30fps.
I was then free to use the full power of OpenCV + Skia 4 Python + DelphiVCL + Cython to get a really high performance image processing framework. 

Yes python can be fast if you roll with it.
Obviously doing everything native in Delphi would be another thing...but it is known that importing libraries written in C++ is still impossible, except in rare cases where someone creates a wrapper in C with undoubted complexity of use.