Re: Are there Python modules that allow a program to write to the screen?

[Chris Angelico]

On Mon, Apr 26, 2021 at 4:40 PM Stephen Tucker  wrote:
>
> Hi,
>
> I have old software written in GWBASIC that I use to plot diagrams on the
> screen.
>
> In Windows 10, I have to resort to using the DOSBox emulator to run it.
>

"The screen" isn't really a viable target in a modern world, so it
depends heavily on what you're trying to do. Plotting diagrams sounds
like you might want matplotlib?

> I would dearly like to re-write it in Python - ideally Python 2.7.
>
> What, if anything, is available?
>

Try Python 3 instead - don't go for something that's already reached
the end of its life.

There are quite a few libraries available, but my first guess would be
matplotlib; and if you want something really fancy, manim can do
incredible things.

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

Re: "py.ini" question

[Gisle Vanem]

Ralf M. wrote:


I think the problem / misunderstanding is that Gisle put in py.ini only
  [defaults]
  python=3.6

and expected this to make py -3 start 3.6. However py -3 looks for a key named 'python3' and, not finding it, uses 
default behaviour (ignoring the 'python' key), i.e. starts the most modern stable 3.x.


The py.ini documentation is a bit hard to find in the help file and hard to understand 


I totally agree with that.


I tried the (rather insane) py.ini
  [defaults]
  python=3.7
  python2=3.8
  python4=2.7
and it works as documented (py -3 shows default behaviour as there is no 
'python3' in py.ini):

C:\>py
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 
bit(AMD64)] on win32
C:\>py -2
Python 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:57:54) [MSC v.1924 64 bit 
(AMD64)] on win32
C:\>py -3
Python 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:57:54) [MSC v.1924 64 bit 
(AMD64)] on win32
C:\>py -4
Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit 
(Intel)] on win32


Thank for confirming what I suspected. And as I wrote earlier:
  Since I'm on a 64-bit Python, a 'py -3' totally seems to ignore
  'py.ini', unless it says:
[defaults]
python3=3.6
python3=3.6-32
---

Except, I meant "Since I'm on a 64-bit Windows" and
 not "Since I'm on a 64-bit Python".
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ad-hoc SQL query builder for Python3?

[Peter J. Holzer]

On 2021-04-25 15:23:57 -0700, Rich Shepard wrote:
> On Sun, 25 Apr 2021, Peter J. Holzer wrote:
> > What should that sql query builder build the queries from? Or in other
> > words what is the user supposed to input?
> 
> Peter,
> 
> From the dialog box offering tables, columns, and rows from which a SELECT
> statement will be constructed.
> 
> This is not a console application with a CLI; it has a GUI so there's no
> direct access to the backend db from within the application.

This is a non-sequitur. To present "tables, columns, and rows" the
application needs access to the database whether the presentation is
done via a graphical or text user interface. Unless these don't change,
then they could be "embedded" in the application - but even then you
would want to execute the the generated SQL queries at some point.

It would have made sense if you had said that it is a web application,
so there is no database connection from the uers's machine to the
database server (only from the web server to the database server). Or
that there is some middleware tier between the application and the
database. But (to me at least) "an application with a GUI" does not
imply either.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

EuroPython 2021: Call for Proposals Open

[M.-A. Lemburg]

We're happy to announce the EuroPython 2021 Call for Proposals (CFP) and
are accepting proposals for talks, training sessions, workshops, panels,
poster sessions, helpdesks and other interactive sessions at EuroPython
2021.

   * EuroPython 2021 Call for Proposals (CFP) *

  https://ep2021.europython.eu/events/call-for-proposals/

We will leave the CFP open from today until
  Sunday, May 9, 23:59:59 CEST.

To submit a proposal, please log in to the site (or create an account
first) and then proceed to the CFP page:

Topics
--

We're looking for proposals on all aspects of Python from novice to
advanced level, including but not limited to: applications, frameworks,
Data Science, internals or topics which you're excited about, your
experiences with Python and its ecosystem and creative or artistic
things you've done with Python.

EuroPython is a community conference and we're eager to hear about how
you use Python in your professional and personal activities.

Feedback has shown that attendees are interested in advanced topics, we
would like to encourage more submissions with an advanced level scope
for EuroPython 2021. Please also note that we have added back training
and workshop submissions. We had to remove those last year due to lack
of resources.

Speaker Mentoring Program
-

This year we are running a mentoring program to encourage more first
time speakers to submit proposals, as well as provide training on
delivering talks effectively. We are also looking for more mentors to
help with the program.

Please check the CFP page for details on the mentoring program.
https://ep2021.europython.eu/events/call-for-proposals/#Speaker-Mentorship-Program


Quick Summary
-
EuroPython 2021 will be run online from July 26 - August 1:

- Two workshop/training days (July 26 - 27)
- Three conference days (July 28 - 30)
- Two sprint days (July 31 - August 1)

The sessions will be scheduled to ensure they are also accessible for
those in the Asian and Americas time zones.


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/europython-2021-call-for-proposals-open-cfp/

Tweet:

https://twitter.com/europython/status/1386631947913400320

Enjoy,
--
EuroPython 2021 Team
https://www.europython-society.org/

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

Problems deploying from poetry development environment

[Loris Bennett]

Hi,

I am developing using poetry and deploying to a directory on an NFS
server.  The steps I have been using are

  1. poetry build
  2. poetry install
  3. PYTHONUSERBASE=/my/nfs/dir pip3 install --user 
~/git/funky_prog/dist/funky_prog-0.2.0-py3-none-any.whl --upgrade

This worked.  The programs got deployed and could be run by other users
on the system.

Now I notice the following problems:

  1. The shebang in the deployed entry point script seems to have
 changed from the system python to the development venv.  So where
 as one program has 

   #!/usr/bin/python3
 
 another, more recent one has 

   
#!/home/loris/.cache/pypoetry/virtualenvs/generate-publications-csv-tiuUP8_d-py3.6/bin/python3
 
 This seems to have happened after a certain date.

  2. Today Step 3 above failed in that the version printed by the
 deployed program stayed the same although a newer version had been
 installed.  I deleted the program directory under 'site-packages'
 along with two 'dist-info' directories (which corresponded to the
 old version and the new version).  Repeating Step 3 now installs
 just the program directory in 'site-packages', but not the
 'dist-info' directory.

The version number is not hard-coded in the program, but is only
contained in the pyproject.toml and exported to METADATA on build.

I have obviously somehow borked the environment.  Does anyone have any
idea how and what I can do to fix it?

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ad-hoc SQL query builder for Python3?

[Rich Shepard]

On Sat, 24 Apr 2021, Rich Shepard wrote:


My web searches are not finding what I need to include in an application I'm
building: an ad-hoc sql query builder.


For those interested I've found a couple of possibilities: PyPika and
SQLbuilder. I'll be looking deeply into them to learn their capabilities.

My model is the query-by-example (QBE) used in Paradox for DOS in the 1980s
and 1990s.

Thanks for all your comments,

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

Re: Problems deploying from poetry development environment

[Loris Bennett]

"Loris Bennett"  writes:

> Hi,
>
> I am developing using poetry and deploying to a directory on an NFS
> server.  The steps I have been using are
>
>   1. poetry build
>   2. poetry install
>   3. PYTHONUSERBASE=/my/nfs/dir pip3 install --user 
> ~/git/funky_prog/dist/funky_prog-0.2.0-py3-none-any.whl --upgrade
>
> This worked.  The programs got deployed and could be run by other users
> on the system.
>
> Now I notice the following problems:
>
>   1. The shebang in the deployed entry point script seems to have
>  changed from the system python to the development venv.  So where
>  as one program has 
>
>#!/usr/bin/python3
>  
>  another, more recent one has 
>
>
> #!/home/loris/.cache/pypoetry/virtualenvs/generate-publications-csv-tiuUP8_d-py3.6/bin/python3
>  
>  This seems to have happened after a certain date.
>
>   2. Today Step 3 above failed in that the version printed by the
>  deployed program stayed the same although a newer version had been
>  installed.  I deleted the program directory under 'site-packages'
>  along with two 'dist-info' directories (which corresponded to the
>  old version and the new version).  Repeating Step 3 now installs
>  just the program directory in 'site-packages', but not the
>  'dist-info' directory.
>
> The version number is not hard-coded in the program, but is only
> contained in the pyproject.toml and exported to METADATA on build.
>
> I have obviously somehow borked the environment.  Does anyone have any
> idea how and what I can do to fix it?

As often happens, writing down the problem for an ML posting helps clear
my mind.

Step 3 has to be carried out *outside* the virtual env used for the
development.  Not doing this leads to the issues above.  

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are there Python modules that allow a program to write to the screen?

[Michael Torrie]

On 4/26/21 12:38 AM, Stephen Tucker wrote:
> Hi,
> 
> I have old software written in GWBASIC that I use to plot diagrams on the
> screen.
> 
> In Windows 10, I have to resort to using the DOSBox emulator to run it.
> 
> I would dearly like to re-write it in Python - ideally Python 2.7.
> 
> What, if anything, is available?
> 
> Stephen Tucker.
> 

Probably this is off-topic for me to say on a Python list, but why not
see if you can compile your GWBASIC program in FreeBASIC[1].  It
supports all graphics commands and screen modes of yesterday and can do
them in a window on modern operating systems.

As for Python, you may find that something like SDL or PyGame provides
primitives that are not far off of what you had in GWBASIC all those
years ago.  As ChrisA has said, Python 2.7 is *not* recommended for any
new projects.

[1] https://www.freebasic.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are there Python modules that allow a program to write to the screen?

[Grant Edwards]

On 2021-04-26, Stephen Tucker  wrote:

> I have old software written in GWBASIC that I use to plot diagrams on the
> screen.

Pygame is probably the closest thing to what you're describing. If you
want to produce professional looking plots from data, then matplotlib
or one of the Gnuplot wrappers (pyGnuplot, py-gnuplot, Gnuplot.py) are
the most obvious choices.

--
Grant


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

c-types Structure and equality with bytes/bytearray

[Michael Hull]

Hello everyone,

I've been working with ctypes recently, and I've come across what seems to
be some slightly confusing behaviour, when comparing ctype's Structure
against `bytes` and `bytearray` objects


import ctypes



class Int(ctypes.Structure):

_fields_ = [("first_16",  ctypes.c_int8),

("second_16", ctypes.c_int8)]



def serialise(self):

return ctypes.string_at(ctypes.addressof(self),

ctypes.sizeof(self))



i_obj= Int(first_16= 65, second_16=66)

print(i_obj.first_16, i_obj.second_16)



i_bytes = i_obj.serialise()

print(list(i_bytes))

assert type(i_bytes) == bytes



i_bytearray = bytearray(i_bytes)





print("obj == bytes =>", i_obj==i_bytes)

print("bytes == obj =>", i_bytes==i_obj)

print("obj == bytearray =>", i_obj==i_bytearray)

print("bytearray == obj =>", i_bytearray==i_obj)




When I run this (Python 3.6, and Python2.7) , the final 4 print statements
give the following:

"""

obj == bytes => False

bytes == obj => False

obj == bytearray => True

bytearray == obj => True

"""

Is this a bit strange -- my understanding was that `bytes` and `bytearray`
would normally be expected to work quite interchangeably with each other?


It also means that:

bytearray == obj   => True

bytes == bytearray => True

bytes == obj   => False


If anyone has any experience in this area, and can let me know if I'm
overlooking something silly, and guidance would be gratefully appreciated.
Alternatively, I am happy to open up a bug-report if this looks like
unexpected behaviour?


Best wishes,



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

Re: "py.ini" question

[Barry Scott]

> On 24 Apr 2021, at 20:56, Gisle Vanem  wrote:
> 
> On that, I'm getting:
>  Requested Python version (0) not installed
> 
> Is that '-0' some 3.9+ feature?

No its a lot older then 3.9 I cannot remember when -0 was first supported
but I've been using -0 for a long long time.

I using the explorer to find c:\windows\py.exe and checked its Properties.
In the Details tar it says that the "Product version" is 3.10.0a5

I think that py.exe gets updated to the highest version.

What does your py.exe show its version as?

Also Are you sure that you are running c:\windows\py.exe?

What happens if you try running c:\windows\py.exe -0?

Barry

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

Re: "py.ini" question

[Barry Scott]

> On 26 Apr 2021, at 09:13, Gisle Vanem  wrote:
> 
> Thank for confirming what I suspected. And as I wrote earlier:
>  Since I'm on a 64-bit Python, a 'py -3' totally seems to ignore
>  'py.ini', unless it says:
>[defaults]
>python3=3.6
>python3=3.6-32

You can prove that py.ini is ignored by using PYLAUNCH_DEBUG but I think its 
that you
do not have the config in the py.ini that does what you want.

As an example is here is the output I see:
C:\Users\barry>set PYLAUNCH_DEBUG=1

C:\Users\barry>py.exe -3
launcher build: 32bit
launcher executable: Console
Using local configuration file 'C:\Users\barry\AppData\Local\py.ini'
File 'C:\WINDOWS\py.ini' non-existent
Called with command line: -3
locating Pythons in 64bit registry
locate_pythons_for_key: C:\Python38.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python38.win32\python.exe is a 32bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python27.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python310.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python34.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python35.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python36.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python37.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
HKLM\SOFTWARE\Python\PythonCore\3.8\InstallPath: The system cannot find the 
file specified.
locate_pythons_for_key: C:\Python39.win64\python.exe is a 64bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locating Pythons in native registry
locate_pythons_for_key: C:\Python38.win64\python.exe: already found
locate_pythons_for_key: C:\Python38.win64\python.exe: already found
locate_pythons_for_key: C:\Python38.win64\python.exe: already found
locate_pythons_for_key: C:\Python38.win64\python.exe: already found
locate_pythons_for_key: C:\Python38.win32\python.exe: already found
locate_pythons_for_key: C:\Python38.win32\python.exe: already found
locate_pythons_for_key: C:\Python38.win32\python.exe: already found
locate_pythons_for_key: C:\Python38.win32\python.exe: already found
locate_pythons_for_key: C:\Python27.win32\python.exe is a 32bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python310.win32\python.exe is a 32bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python34.win32\python.exe is a 32bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: C:\Python35.win32\python.exe is a 32bit executable
locate_pythons_for_key: : The system cannot find the path specified.
locate_pythons_for_key: : The system cannot find t

Re: async watch directory for new files

[Barry Scott]

> On 24 Apr 2021, at 21:12, Zoran  wrote:
> 
> As I can see https://pypi.org/project/inotify/ 
>  is not asyncio frendly.
> Whatever I use, it should be asynchronous. 
> Final OS is linux (Centos 7), but I am doing development on Windows 10 
> machine, so it would be nice if I have something that works on both.

In this case trying to develop the code on Windows will make your life very 
hard.

Are you using Windows because you do not have easy access to Centos 7?
If so why not run Centos 7 in a VM on your Windows machine as your dev 
environment?

Barry

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

Not found in the documentation

[elas tica]

Python documentation doesn't seem to mention anywhere what is the str value of 
an int: is it right?  the same for float, Fraction, complex, etc? Not worth to 
be documented? Perphaps str(42) returns "forty two" or "XLII" or "101010" ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not found in the documentation

[Paul Bryan]

From 
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
:

> The string representations of the numeric classes, computed
> by__repr__() and __str__(), have the following properties:
>  * They are valid numeric literals which, when passed to their
>class constructor, produce an object having the value of the
>original numeric.
>  * The representation is in base 10, when possible.
>  * Leading zeros, possibly excepting a single zero before a
>decimal point, are not shown.
>  * Trailing zeros, possibly excepting a single zero after a
>decimal point, are not shown.
>  * A sign is shown only when the number is negative.

Paul

On Mon, 2021-04-26 at 16:24 -0700, elas tica wrote:
> 
> Python documentation doesn't seem to mention anywhere what is the str
> value of an int: is it right?  the same for float, Fraction, complex,
> etc? Not worth to be documented? Perphaps str(42) returns "forty two"
> or "XLII" or "101010" ...

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

Re: Not found in the documentation

[elas tica]

Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit :
> From 
> https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
>  
> : 
> 


Thanks for the reference. I was expecting to find this information in the 
Built-in Types section from the PSL documentation. The representation returned 
by str over a complex number is not stated. The same for fraction objects. All 
the docstrinds are meaningless, showing :

__str__(self)
str(self)
(END)

not very informative.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not found in the documentation

[2QdxY4RzWzUUiLuE]

On 2021-04-26 at 18:24:18 -0700,
elas tica  wrote:

> [...] I was expecting to find [a description of what str returns for
> various types] in the Built-in Types section from the PSL
> documentation. The representation returned by str over a complex
> number is not stated. The same for fraction objects [...]

Assuming that PSL is the Python Standard Library,
https://docs.python.org/3/library/functions.html#func-str says:

[...] str(object) returns object.__str__(), which is the “informal”
or nicely printable string representation of object [...]

IMO, an exhaustive list of exactly what that means for every type, even
the built in types, is unnecessary, and could create maintenance or
compatibility issues.

Is there a reason you need that information?  What would you do with it
if you had it?  Completely speculatively on my part, would repr
(https://docs.python.org/3/library/functions.html#repr) meet your
need(s) better than str?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not found in the documentation

[Paul Bryan]

I agree. I would be useful for it to be documented elsewhere,
especially in docstrings. I wonder if this is/was a conscious decision
to keep Python runtime smaller?

Paul

On Mon, 2021-04-26 at 18:24 -0700, elas tica wrote:
> Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit :
> > From
> > https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
> >  
> > : 
> > 
> 
> 
> Thanks for the reference. I was expecting to find this information in
> the Built-in Types section from the PSL documentation. The
> representation returned by str over a complex number is not stated.
> The same for fraction objects. All the docstrinds are meaningless,
> showing :
> 
> __str__(self)
>     str(self)
> (END)
> 
> not very informative.

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

Re: Ad-hoc SQL query builder for Python3?

[Robert Latest via Python-list]

Rich Shepard wrote:
> For those interested I've found a couple of possibilities: PyPika and
> SQLbuilder. I'll be looking deeply into them to learn their capabilities.

In case nobody mentioned it before, don't forget to take a look at SQLAlchemy.
The object-relational-mapper (ORM) creates a 1:1 mapping of Python objects to
SQL table rows.

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