Has anone seen or know of a CFFI wrapper for PDCurses?

[pjfarley3]

Hi All,

I have been investigating the possibility of wrapping the PDCurses DLL on
Windows (or even better the PDCursesMod fork) using cffi instead of ctypes. 
The unicurses project tried this using ctypes 11 years ago but unicurses
hasn't been worked on since 2010, and it shows its age.

I think I have figured out a reasonably clean way to do it using the cffi
ABI interface with a "cleaned up" copy of the provided "curses.h" header
(using the API interface looks to me like it would be quite a bit more work
for this library; not impossible, but a lot more work).

Before I go down this path I wanted to ask here if anyone else has already
been down that way, or knows of a project that wen that way, and if so what
roadblocks and/or successes were seen?

I also asked this question on the cffi mailing list, but that seems to be a
low-traffic list.  In any case, I haven't gotten any response there yet.

TIA for any references or advice you can offer.

Peter


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

Re: Has anone seen or know of a CFFI wrapper for PDCurses?

[Dan Stromberg]

On Sun, Jun 13, 2021 at 12:50 AM  wrote:

> Hi All,
>
> I have been investigating the possibility of wrapping the PDCurses DLL on
> Windows (or even better the PDCursesMod fork) using cffi instead of
> ctypes.
> The unicurses project tried this using ctypes 11 years ago but unicurses
> hasn't been worked on since 2010, and it shows its age.
>

An option for your consideration: Maybe port Python's included curses
module to PDCursesMod?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: EU language skills, and Master to Main (or ...)

[jan via Python-list]

Hi,
see below

On 13/06/2021, dn via Python-list  wrote:
> [to folk subscribed to both the Python list and Python-Tutor: apologies
> for cross-posting]
>
>
> Regarding levels of skill or complexity in learning, the European Union
> has been working on "The Common European Framework of Reference for
> Languages: Learning, Teaching, Assessment". It also standardises
> terminology for spoken/national-language training courses.
> https://en.wikipedia.org/wiki/Common_European_Framework_of_Reference_for_Languages

To re-state what you already said but I didn't pick up on, this is
natural spoken languages.

[snip]

>
> A group at the King Juan-Carlos University (Madrid, Spain) is collecting
> practitioners' opinions in a bid to categorise Python mastery according
> to the Framework. You may like to contribute by responding to their
> research surveys (one form takes five-minutes, the other fifteen):
> https://docs.google.com/forms/d/e/1FAIpQLSdlzWGpvZHLHXl6iEdHbLTB6QvYXknrD9-JKmzY7riYJkPmNw/viewform

Also I'm not sure there's much to relate artificial (programming)
languages with natural (spoken) ones.

'Mastery; of python programming is almost meaningless because if you
are a decent programmer you will be able to pick up new paradigms
*reasonably* straightforwardly, and paradignms thus internalised
(functional/OO/procedural/logic/etc) will then transfer fairly easily
across languages.

Also it's about problem solving which is an independent skill altogether.

Also it includes transferrable prior experiences and
knowledge/exposure ("IThere's a library for that" / "regexps are a
trap here" / "just use a parser generator, don't write it by hand" /
"The largest element every time? Let me introduce you to the Heap data
structure" / "if you stick a bloom filter in front of that you can cut
out 90% of database accesses here")

If you're a good scala programmer it will take only a few weeks to get
up to speed with python - I've done it. Most of that time went on
learning the libraries (of python, and scala) anyway.

>
>
> I like to label tutorials and conference-talks (and sometimes individual
> slides/sections) to indicate levels of complexity. However, have
> replaced abstract terms such as "Beginner" or "Junior", "Intermediate",
> and "Advanced" or "Senior" which all sound school-ish; with the three
> terms: "Apprentice", "Journeyman", and "Master" (see also
> https://leanpub.com/b/python-craftsman).

Just words.

>
[snip]

>
> There is a potential-problem in the rising sensitivity of the word
> "Master", eg the git CVS has replaced the idea of a Master-branch with
> "Main branch" (or user-chosen alternative name). Will referring to
> skilled professionals as 'masters (of their profession/craft)'
> transgress (international or at least US-instigated) 'Political
> Correctness'?

I've never seen any of this at my workplaces. When I occasionally read
about this on the web and follow up to the source posts of those doing
this, my impression is there are a few, vocal people who are just
there to disrupt rather than do anything constructive.
That may be reporting bias though so my view may be of questionable reliability.

Basically I've not seen much if any value in this PC stuff.

>
>
> What do you think a professionally-recognisable series of skill-levels
> for programmers?

Fine. If you can do it in any meaningful sense.

jan

>
> --
> Regards,
> =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Has anone seen or know of a CFFI wrapper for PDCurses?

[pjfarley3]

> From: Dan Stromberg  
> Sent: Monday, June 14, 2021 12:36 AM
> To: pjfarl...@earthlink.net
> Cc: Python List 
> Subject: Re: Has anone seen or know of a CFFI wrapper for PDCurses?
>
> > On Sun, Jun 13, 2021 at 12:50 AM  wrote:
> > Hi All,
> >
> > I have been investigating the possibility of wrapping the PDCurses DLL on
> > Windows (or even better the PDCursesMod fork) using cffi instead of ctypes. 
> > The unicurses project tried this using ctypes 11 years ago but unicurses
> > hasn't been worked on since 2010, and it shows its age.
>
> An option for your consideration: Maybe port Python's included curses module 
> to PDCursesMod?

An interesting idea, to be sure, and one I have looked at to some extent.  One 
thing that I've never quite learned is whether the included curses and 
curses_panel modules statically link a copy of the ncurses library on *ix 
systems or whether they invoke the ncurses.so library dynamically.

If it is designed to invoke the ncurses and panels subroutines from the shared 
library it could be a possible path.

One obstacle I thought that I saw is that building cpython modules based on 
non-python library sources AssUMes that the build process can get the library 
source from the cpython repository, rather than from a non-python external 
source repository.  I have built some scripts to get around that assumption, 
but they would have to be integrated into the cpython external library build 
process for any wide distribution.

And there are some differences between the PDCurses and ncurses assumed 
internal structures and what is externalized and what is not that might make 
that harder than it first appears.

Plus taking that path really does requires the porter to learn at least the 
generics of the cpython internal macros and functions in order to be able to 
debug the result, which is a little bit daunting.  Not impossible, but many 
molehills look like mountains to the uninitiated.

Anyway, I am just investigating options at present, so thanks for the 
suggestion.

Peter


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