Re: XML Considered Harmful

[Mike Dewhirst via Python-list]

I had to use XML once because that was demanded by the receiving machine over 
which I had no say.I wouldn't use it otherwise because staring at it makes you 
dizzy.I would want to know how the data are derived from the multiple sources 
and transmitted to the collating platform before pontificating.Then I would 
ignore any potential future enhancements and choose the easiest possible 
mechanism. I have used json with python and been delighted at the ease of 
converting data into dicts and even arbitrary nesting where data values can 
also be dicts etc.Good luck--(Unsigned mail from my phone)
 Original message From: dn via Python-list 
 Date: 24/9/21  15:42  (GMT+10:00) To: 
python-list@python.org Subject: Re: XML Considered Harmful On 24/09/2021 14.07, 
Stefan Ram wrote:> dn  writes:>> With that, why 
not code it as Python expressions, and include the module?> >   This might 
create a code execution vulnerability if such >   files are exchanged between 
multiple parties.The OP's spec, as quoted earlier(!), reads:"It's my own 
research, so I can give myself the data in any format thatI like."Whither 
"files are exchanged" and/or "multiple parties"? Are theseanticipations of 
problems that may/won't ever apply? aka YAGNI.Concern about such an approach 
*is* warranted.However, the preceding question to be considered during the 
design-stageis: 'does such concern apply?'. The OP describes full and unique 
agency.Accordingly, "KISS"!NB my personal choice would likely be JSON or YAML, 
but see reservations(eg @Chris) - and with greater relevance: shouldn't we 
consider the OP's'learning curve'?(such deduced only from OP's subsequent 
reactions/responses 'here' -with any and all due apologies)-- Regards,=dn-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Type annotation pitfall

[Robert Latest via Python-list]

Hi all,

this just caused me several hours of my life until I could whittle it down to
this minimal example. Simple question: Why is the x member of object "foo"
modified by initializing "bar"?

Obviously, initializing foo with None doesn't set foo.x at all. So I guess x
stays a class property, not an instance property. And instantiating bar just
added an item to the class property but didn't instantiate a new set. So
basically, neither foo nor bar ever had their "own" x, right?

Oooohh, dangerous! Never use mutable types in type hint, unless it's in
explicit dataclasses (which automatically add an appropriate __init__()?)

Now I must fine-comb all my code for more of these.

class Foo():
x : set = set()

def __init__(self, s):
if s:
self.x.add(s)

foo = Foo(None)
print(foo.x) # prints 'set()'
bar = Foo('abc')
print(foo.x) # prints '{'abc'}

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

Re: XML Considered Harmful

[dn via Python-list]

On 24/09/2021 14.07, Stefan Ram wrote:
> dn  writes:
>> With that, why not code it as Python expressions, and include the module?
> 
>   This might create a code execution vulnerability if such 
>   files are exchanged between multiple parties.


The OP's spec, as quoted earlier(!), reads:

"It's my own research, so I can give myself the data in any format that
I like."

Whither "files are exchanged" and/or "multiple parties"? Are these
anticipations of problems that may/won't ever apply? aka YAGNI.

Concern about such an approach *is* warranted.

However, the preceding question to be considered during the design-stage
is: 'does such concern apply?'. The OP describes full and unique agency.
Accordingly, "KISS"!

NB my personal choice would likely be JSON or YAML, but see reservations
(eg @Chris) - and with greater relevance: shouldn't we consider the OP's
'learning curve'?
(such deduced only from OP's subsequent reactions/responses 'here' -
with any and all due apologies)
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Flush / update GUIs in PyQt5 during debugging in PyCharm

[Mohsen Owzar]

Hi Guys
I've written a GUI using PyQt5 and in there I use StyleSheets (css) for the 
buttons and labels to change their background- and foreground-colors and their 
states as well.
Because my program doesn't function correctly, I try to debug it in my IDE 
(PyCharm).
The problem is that during debugging, when I change some attributes of a button 
or label, let say its background-color, I can not see this modification of the 
color until the whole method or function is completed.
I believe that I have seen somewhere during my searches and googling that one 
can flush or update the GUI after each step/action is done.
But until now I couldn't manage it and I don't know where I have to invoke 
flush/update command in PyCharm.
If anyone has done this before and knows about it, I would very appreciate 
seeing his solution.

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

When should I use "parent=None" in __ini__ and "parent" in super()

[Mohsen Owzar]

Hi Guys
I'm writing since almost one-year codes in Python, using TKinter and PyQt5.
I'm somehow able to writes GUIs in both of them.
But since I'm using more Pyqt5 and using classes with initialization and 
super() constructs, and also I saw lots of videos and examples of coding them, 
I still don’t know exactly how and when should I use the parent in __init()__ 
and super() construct.
For example, the following lines use "parent=None" in the __init__ construct 
and "parent" in the super() construct. And sometimes I do not see any of them 
in these two constructs.

class MyClass1(QWidget):
def __init__(self, name, parent=None):
super(MyClass1, self).__init__(parent)
print(self.parent().test)

And sometimes without "parent" like the following:

class MyClass2(QWidget):
def __init__(self, name):
super(MyClass2, self).__init__()
print(self.parent().test)

Could anyone explain this to me when and for which action I have to use the 
first one "MyClass1" and when the second one "MyClass2"?

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

Re: XML Considered Harmful

[Chris Angelico]

On Fri, Sep 24, 2021 at 1:44 PM Dan Stromberg  wrote:
>
>
> On Thu, Sep 23, 2021 at 8:12 PM Chris Angelico  wrote:
>>
>> One good hybrid is to take a subset of Python syntax (so it still
>> looks like a Python script for syntax highlighting etc), and then
>> parse that yourself, using the ast module. For instance, you can strip
>> out comments, then look for "VARNAME = ...", and parse the value using
>> ast.literal_eval(), which will give you a fairly flexible file format
>> that's still quite safe.
>
>
> Restricting Python with the ast module is interesting, but I don't think I'd 
> want to bet my career on the actual safety of such a thing.  Given that Java 
> bytecode was a frequent problem inside web browsers, imagine all the 
> messiness that could accidentally happen with a subset of Python syntax from 
> untrusted sources.
>
> ast.literal_eval might be a little better - or a list of such, actually.

Uhh, I specifically mention literal_eval in there :) Simple text
parsing followed by literal_eval for the bulk of it is a level of
safety that I *would* bet my career on.

> Better still to use JSON or ini format - IOW something designed for the 
> purpose.

It all depends on how human-editable it needs to be. JSON has several
problems in that respect, including some rigidities, and a lack of
support for comments. INI format doesn't have enough data types for
many purposes. YAML might be closer, but it's not for every situation
either.

That's why we have options.

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

Re: XML Considered Harmful

[Dan Stromberg]

On Thu, Sep 23, 2021 at 8:12 PM Chris Angelico  wrote:

> One good hybrid is to take a subset of Python syntax (so it still
> looks like a Python script for syntax highlighting etc), and then
> parse that yourself, using the ast module. For instance, you can strip
> out comments, then look for "VARNAME = ...", and parse the value using
> ast.literal_eval(), which will give you a fairly flexible file format
> that's still quite safe.
>

Restricting Python with the ast module is interesting, but I don't think
I'd want to bet my career on the actual safety of such a thing.  Given that
Java bytecode was a frequent problem inside web browsers, imagine all the
messiness that could accidentally happen with a subset of Python syntax
from untrusted sources.

ast.literal_eval might be a little better - or a list of such, actually.

Better still to use JSON or ini format - IOW something designed for the
purpose.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Chris Angelico]

On Fri, Sep 24, 2021 at 12:22 PM Stefan Ram  wrote:
>
> dn  writes:
> >With that, why not code it as Python expressions, and include the module?
>
>   This might create a code execution vulnerability if such
>   files are exchanged between multiple parties.
>
>   If code execution vulnerabilities and human-readability are
>   not an issue, then one could also think about using pickle.
>
>   If one ignores security concerns for a moment, serialization into
>   a text format and subsequent deserialization can be a easy as:
>
> |>>> eval( str( [1, (2, 3)] ))
> |[1, (2, 3)]
>

One good hybrid is to take a subset of Python syntax (so it still
looks like a Python script for syntax highlighting etc), and then
parse that yourself, using the ast module. For instance, you can strip
out comments, then look for "VARNAME = ...", and parse the value using
ast.literal_eval(), which will give you a fairly flexible file format
that's still quite safe.

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

Re: XML Considered Harmful

[dn via Python-list]

On 22/09/2021 07.22, Michael F. Stemper wrote:
> On 21/09/2021 13.49, alister wrote:
>> On Tue, 21 Sep 2021 13:12:10 -0500, Michael F. Stemper wrote:
>>
>>> On the prolog thread, somebody posted a link to:
>>> 

Given the source, shouldn't one take any criticism of Python (or Java)
with at least the proverbial grain of salt!


>>> One thing that it tangentially says is "XML is not the answer."

"tangential" as in 'spinning off'?


...

> It's my own research, so I can give myself the data in any format that I
> like.
...
With that, why not code it as Python expressions, and include the module?
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Jon Ribbens via Python-list]

On 2021-09-23, Stefan Ram  wrote:
>   The real problem with CSV is that there is no CSV.
>
>   This is not a specific data language with a specific
>   specification. Instead it is a vague designation for
>   a plethora of CSV dialects, which usually dot not even
>   have a specification.

Indeed. For example, at least at some points in its history,
Excel has been unable to import CSV written by itself, because
its importer was incompatible with its own exporter.

>   Compare this with XML. XML has a sole specification managed
>   by the W3C.

Other well-defined formats are also available ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Chris Angelico]

On Fri, Sep 24, 2021 at 7:11 AM Eli the Bearded <*@eli.users.panix.com> wrote:
>
> In comp.lang.python, Christian Gollwitzer   wrote:
> > Am 22.09.21 um 16:52 schrieb Michael F. Stemper:
> >> On 21/09/2021 19.30, Eli the Bearded wrote:
> >>> Yes, CSV files can model that. But it would not be my first choice of
> >>> data format. (Neither would JSON.) I'd probably use XML.
> >> Okay. 'Go not to the elves for counsel, for they will say both no
> >> and yes.' (I'm not actually surprised to find differences of opinion.)
>
> Well, I have a recommendation with my answer.
>
> > It's the same as saying "CSV supports images". Of course it doesn't, its
> > a textfile, but you could encode a JPEG as base64 and then put this
> > string into the cell of a CSV table. That definitely isn't what a sane
> > person would understand as "support".
>
> I'd use one of the netpbm formats instead of JPEG. PBM for one bit
> bitmaps, PGM for one channel (typically grayscale), PPM for three
> channel RGB, and PAM for anything else (two channel gray plus alpha,
> CMYK, RGBA, HSV, YCbCr, and more exotic formats). JPEG is tricky to
> map to CSV since it is a three channel format (YCbCr), where the
> channels are typically not at the same resolution. Usually Y is full
> size and the Cb and Cr channels are one quarter size ("4:2:0 chroma
> subsampling"). The unequal size of the channels does not lend itself
> to CSV, but I can't say it's impossible.
>

Examine prior art, and I truly do mean art, from Matt Parker:

https://www.youtube.com/watch?v=UBX2QQHlQ_I

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

RE: XML Considered Harmful

[Avi Gross via Python-list]

What you are describing Stephen, is what I meant by emulating a relational 
database with tables.

And, FYI, There is no guarantee that two authors with the same name will not be 
assumed to be the same person.

Besides the lack of any one official CSV format, there are oodles of features I 
have seen that are normally external to the CSV. For example, I have often read 
in data from a CSV or similar, where you could tell the software to consider a 
blank or 999 to mean NA and what denotes a line in the file to be ignored as a 
comment and whether a separator is a space or any combination of whitespace and 
what quotes something so say you can hide a comma and how to handle escapes and 
whether to skip blank lines and more.

Now a really good design might place some metadata into the file that can be 
used to set defaults for things like that or incorporate them into the format 
unambiguously. It might calculate the likely data type for various fields and 
store that in the metadata. So even if you stored rectangular data in a CSV 
file, perhaps the early lines would be in some format that can be read as 
comments and supply some info like the above.

Are any of the CSV variants more like that?

-Original Message-
From: Python-list  On 
Behalf Of Stefan Ram
Sent: Thursday, September 23, 2021 5:43 PM
To: python-list@python.org
Subject: Re: XML Considered Harmful

"Avi Gross"  writes:
>But scientific papers seemingly allow oodles of authors and any time 
>you update the data, you may need yet another column.

  You can use three CSV files: papers, persons, and authors:

  papers.csv

1, "Is the accelerated expansion evidence of a change of signature?"

  persons.csv

1, Marc Mars

  authors.csv

1, 1

  I.e., paper 1 is authored by person 1.

  Now, when we learn that José M. M. Senovilla also is a
  co-author of "Is the accelerated expansion evidence of a
  forthcoming change of signature?", we do only have to add
  new rows, no new colums.

  papers.csv

1, "Is the accelerated expansion evidence of a change of signature?"

  persons.csv

1, "Marc Mars"
2, "José M. M. Senovilla"

  authors.csv

1, 1
1, 2

  The real problem with CSV is that there is no CSV.

  This is not a specific data language with a specific
  specification. Instead it is a vague designation for
  a plethora of CSV dialects, which usually dot not even
  have a specification. Compare this with XML. XML has
  a sole specification managed by the W3C.


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

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

RE: XML Considered Harmful

[Avi Gross via Python-list]

Can we agree that there are way more general ways to store data than
anything currently in common use and that in some ways, CSV and cousins like
TSV are a subset of the others in a sense? There are trees and arbitrary
graphs and many complex data structures often encountered while a program is
running as in-memory objects. Many are not trivial to store.

But some are if all you see is table-like constructs including matrices and
data.frames.

I mean any rectangular data format with umpteen rows and N columns can
trivially be stored in many other formats and especially when it allows some
columns to have NA values. The other format would simply have major
categories that contain components with one per column, and if missing,
represents an NA. Is there any reason JSON or XML cannot include the
contents of any CSV with headers and without loss of info?

Going the other way is harder. Note that a data.frame type of structure
often imposes restrictions on a CSV and requires everything in a column to
be of the same type, or coercible to a common type. (well, not always true
as in using list columns in R.)  But given some arbitrary structure in XML,
can you look at all possible labels and if it is not too complex, make a CSV
with one or more columns for every possible need? It can be a problem if say
a record for an Author allows multiple actual co-authors. Normal books may
let you get by with multiple columns (mostly containing an NA) with names
like author1, author2, author3, ...

But scientific papers seemingly allow oodles of authors and any time you
update the data, you may need yet another column. And, of course, processing
data where many columns have the same meaning is a bit of a pain. Data
structures can also often be nested multiple levels and at some point, CSV
is not a reasonable fit unless you play database games and make multiple
tables you can store and retrieve to make complex queries, as in many
relational database systems. Yes, each such table can be a CSV.

But if you give someone a hammer, they tend to stop using thumbtacks or
other tools. The real question is what kind of data makes good sense for an
application. If a nice rectangular format works, great. Even if not, the
Author problem above can fairly easily be handled by making the author
column something like a character string you compose as "Last1, First1;
Last2, First2; Last3, First3" and that fits fine in a CSV but can be taken
apart in your software if looking for any book by a particular author. Not
optimal, but a workaround I am sure is used.

But using the most abstract and complex storage method is very often
overkill and unless you are very good at it, may well be a fairly slow and
even error-prone way to solve a problem.

-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Thursday, September 23, 2021 9:27 AM
To: Python 
Subject: Re: XML Considered Harmful

On Thu, Sep 23, 2021 at 10:55 PM Mats Wichmann  wrote:
>
> On 9/22/21 10:31, Dennis Lee Bieber wrote:
>
> >   If you control both the data generation and the data 
> > consumption, finding some format  ...
>
> This is really the key.  I rant at people seeming to believe that csv 
> is THE data interchange format, and it's about as bad as it gets at 
> that, if you have a choice.  xml is noisy but at least (potentially) 
> self-documenting, and ought to be able to recover from certain errors.
> The problem with csv is that a substantial chunk of the world seems to 
> live inside Excel, and so data is commonly both generated in csv so it 
> can be imported into excel and generated in csv as a result of 
> exporting from excel, so the parts often are *not* in your control.
>
> Sigh.

The only people who think that CSV is *the* format are people who habitually
live in spreadsheets. People who move data around the internet, from program
to program, are much more likely to assume that JSON is the sole format. Of
course, there is no single ultimate data interchange format, but JSON is a
lot closer to one than CSV is.

(Or to be more precise: any such thing as a "single ultimate data
interchange format" will be so generic that it isn't enough to define
everything. For instance, "a stream of bytes" is a universal data
interchange format, but that's not ultimately a very useful claim.)

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

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

Re: XML Considered Harmful

[Michael F. Stemper]

On 23/09/2021 12.51, Eli the Bearded wrote:

Am 22.09.21 um 16:52 schrieb Michael F. Stemper:

On 21/09/2021 19.30, Eli the Bearded wrote:

Yes, CSV files can model that. But it would not be my first choice of
data format. (Neither would JSON.) I'd probably use XML.

Okay. 'Go not to the elves for counsel, for they will say both no
and yes.' (I'm not actually surprised to find differences of opinion.)


Well, I have a recommendation with my answer.


Sorry, didn't mean that to be disparaging.

--
Michael F. Stemper
This post contains greater than 95% post-consumer bytes by weight.
--
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Michael F. Stemper]

On 22/09/2021 17.37, Dennis Lee Bieber wrote:

On Wed, 22 Sep 2021 09:52:59 -0500, "Michael F. Stemper"
 declaimed the following:

On 21/09/2021 19.30, Eli the Bearded wrote:

In comp.lang.python, Michael F. Stemper  wrote:



How does CSV handle hierarchical data? For instance, I have



Can CSV files model this sort of situation?





Yes, CSV files can model that. But it would not be my first choice of
data format. (Neither would JSON.) I'd probably use XML.


Okay. 'Go not to the elves for counsel, for they will say both no
and yes.' (I'm not actually surprised to find differences of opinion.)


You'd have to include a "level" (and/or data type if multiple objects
can be at the same level) field (as the first field) in CSV which
identifies how to parse the rest of the CSV data (well, technically, the
CSV module has "parsed" it -- in terms of splitting at commas, handling
quoted strings (which may contain commas which are not split points, etc.).

1-generator, name
2-fuel, name, UOM, heat-content, price
2-curve, name
3-point, X, Y
3-point, X, Y
...
2-curve, name
3-point, X, Y
3-point, X, Y


This reminds me of how my (former) employer imported data models into
our systems from the 1970s until the mid-2000s. We had 80-column records
(called "card images"), that would have looked like:

FUEL0 LIGNITETON13.610 043.581
UNIT1 COAL CREK1
UNIT2 ...

The specific columns for the start and end of each field on each record
were defined in a thousand-plus page document. (We modeled all of a
power system, not just economic data about generators.)

However, this doesn't seem like it would fit too well with the csv
module, since it requires a lot more logic on the part of the consuming
program.

Interesting flashback, though.

--
Michael F. Stemper
Deuteronomy 24:17
--
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Christian Gollwitzer]

Am 22.09.21 um 16:52 schrieb Michael F. Stemper:

On 21/09/2021 19.30, Eli the Bearded wrote:

Yes, CSV files can model that. But it would not be my first choice of
data format. (Neither would JSON.) I'd probably use XML.


Okay. 'Go not to the elves for counsel, for they will say both no
and yes.' (I'm not actually surprised to find differences of opinion.)


It is wrong, CSV has no model of hierarchical data. A CSV file is a 2d 
table, just like a database table or an Excel sheet.


You can /layer/ high-dimensional data on top of a 2D table, there is the 
relational algebra theory behind this, but it is wrong (or misleading at 
best) to say that CSV can model hierarchical data.


It's the same as saying "CSV supports images". Of course it doesn't, its 
a textfile, but you could encode a JPEG as base64 and then put this 
string into the cell of a CSV table. That definitely isn't what a sane 
person would understand as "support".


Christian

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

Re: XML Considered Harmful

[Eli the Bearded]

In comp.lang.python, Christian Gollwitzer   wrote:
> Am 22.09.21 um 16:52 schrieb Michael F. Stemper:
>> On 21/09/2021 19.30, Eli the Bearded wrote:
>>> Yes, CSV files can model that. But it would not be my first choice of
>>> data format. (Neither would JSON.) I'd probably use XML.
>> Okay. 'Go not to the elves for counsel, for they will say both no
>> and yes.' (I'm not actually surprised to find differences of opinion.)

Well, I have a recommendation with my answer.

> It's the same as saying "CSV supports images". Of course it doesn't, its 
> a textfile, but you could encode a JPEG as base64 and then put this 
> string into the cell of a CSV table. That definitely isn't what a sane 
> person would understand as "support".

I'd use one of the netpbm formats instead of JPEG. PBM for one bit
bitmaps, PGM for one channel (typically grayscale), PPM for three
channel RGB, and PAM for anything else (two channel gray plus alpha,
CMYK, RGBA, HSV, YCbCr, and more exotic formats). JPEG is tricky to
map to CSV since it is a three channel format (YCbCr), where the
channels are typically not at the same resolution. Usually Y is full
size and the Cb and Cr channels are one quarter size ("4:2:0 chroma
subsampling"). The unequal size of the channels does not lend itself
to CSV, but I can't say it's impossible.

But maybe you meant the whole JFIF or Exif JPEG file format base64
encoded with no attempt to understand the image. That sort of thing
is common in JSON, and I've seen it in YAML, too. It wouldn't surprise
me if people do that in CSV or XML, but I have so far avoided seeing
that. I used that method for sticking a tiny PNG in a CSS file just
earlier this month. The whole PNG was smaller than the typical headers
of an HTTP/1.1 request and response, so I figured "don't make it a
separate file".

Elijah
--
can at this point recegnize a bunch of "magic numbers" in base64


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

Re: Free OCR package in Python and selecting appropriate widget for the GUI

[Mohsen Owzar]

DFS schrieb am Mittwoch, 22. September 2021 um 09:41:42 UTC+2:
> On 9/22/2021 1:54 AM, Mohsen Owzar wrote: 
> > DFS schrieb am Mittwoch, 22. September 2021 um 05:10:30 UTC+2: 
> >> On 9/21/2021 10:38 PM, Mohsen Owzar wrote: 
> >>> DFS schrieb am Dienstag, 21. September 2021 um 15:45:38 UTC+2: 
>  On 9/21/2021 4:36 AM, Mohsen Owzar wrote: 
> > Hi Guys 
> > Long time ago I've written a program in Malab a GUI for solving Sudoku 
> > puzzles, which worked not so bad. 
> > Now I try to write this GUI with Python with PyQt5 or TKinter. 
> > First question is: 
> > Is there any free OCR software, packages or code in Python, which I can 
> > use to recognize the given digits and their positions in the puzzle 
> > square. 
> > Second: 
> > Because, I can not attach a picture to this post, I try to describe my 
> > picture of my GUI. 
>  Draw your GUI in PyQt designer or other graphics tool, then upload a 
>  screenshot of it to imgur, then post the link to the picture. 
> >>> Thanks, for your answer. 
> >>> But, what is "imgur"? 
> >>> I'm not so familiar with handling of pictures in this group. 
> >>> How can I call "imgur" or how can I get there? 
> >>> 
> >>> Regards 
> >>> Mohsen 
> >> www.imgur.com 
> >> 
> >> It's a website you can upload image files or screenshots to. Then you 
> >> can copy a link to your picture and post the link here. 
> > I have already posted the link, but I can not see it anywhere. 
> > Now, I post it again: 
> > https://imgur.com/a/Vh8P2TE 
> > I hope that you can see my two images. 
> > Regards 
> > Mohsen
> Got it. 
> 
> I haven't used tkinter. In PyQt5 designer I think you should use one 
> QTextEdit control for each square. 
> 
> 
> Each square with the small black font can be initially populated with 
> 
> 1 2 3 
> 4 5 6 
> 7 8 9 
> 
> 
> 
> https://imgur.com/lTcEiML 
> 
> 
> 
> some starter python code (maybe save as sudoku.py) 
> 
> = 
> from PyQt5 import Qt, QtCore, QtGui, QtWidgets, uic 
> from PyQt5.Qt import * 
> from PyQt5.QtCore import * 
> from PyQt5.QtGui import * 
> from PyQt5.QtWidgets import * 
> 
> #objects 
> app = QtWidgets.QApplication([]) 
> frm = uic.loadUi("sudoku.ui") 
> 
> 
> #grid = a collection of squares 
> grids = 1 
> 
> #squares = number of squares per grid 
> squares = 9 
> 
> #fill the squares with 1-9 
> def populateSquares(): 
> for i in range(grids,grids+1): 
> for j in range(1,squares+1): 
> widget = frm.findChild(QtWidgets.QTextEdit, "txt{}_{}".format(i,j)) 
> widget.setText("1 2 3 4 5 6 7 8 9") 
> 
> #read data from squares 
> def readSquares(): 
> for i in range(grids,grids+1): 
> for j in range(1,squares+1): 
> print("txt%d_%d contains: %s" % 
> (i,j,frm.findChild(QtWidgets.QTextEdit, 
> "txt{}_{}".format(i,j)).toPlainText())) 
> 
> 
> #connect pushbuttons to code 
> frm.btnPopulate.clicked.connect(populateSquares) 
> frm.btnReadContents.clicked.connect(readSquares) 
> 
> #show main form 
> frm.show() 
> 
> #initiate application 
> app.exec() 
> = 
> 
> 
> 
> 
> 
> .ui file (ie save as sudoku.ui) 
> = 
> 
>  
>  
> MainWindow 
>  
>  
>  
> 0 
> 0 
> 325 
> 288 
>  
>  
>  
> Sudoku 
>  
>  
>  
>  
>  
> 32 
> 22 
> 83 
> 65 
>  
>  
>  
>  
> Courier 
> 12 
> 50 
> false 
>  
>  
>  
> false 
>  
>  
> color: rgb(0, 0, 127); 
> background-color: rgb(255, 255, 127); 
>  
>  
> QFrame::StyledPanel 
>  
>  
> QFrame::Sunken 
>  
>  
> Qt::ScrollBarAlwaysOff 
>  
>  
> true 
>  
>  
>  
>  
>  
> 114 
> 22 
> 83 
> 65 
>  
>  
>  
>  
> Courier 
> 12 
> 50 
> false 
>  
>  
>  
> false 
>  
>  
> color: rgb(0, 0, 127); 
> background-color: rgb(255, 255, 127); 
>  
>  
> QFrame::StyledPanel 
>  
>  
> QFrame::Sunken 
>  
>  
> Qt::ScrollBarAlwaysOff 
>  
>  
> true 
>  
>  
>  
>  
>  
> 196 
> 22 
> 83 
> 65 
>  
>  
>  
>  
> Courier 
> 12 
> 50 
> false 
>  
>  
>  
> false 
>  
>  
> color: rgb(0, 0, 127); 
> background-color: rgb(255, 255, 127); 
>  
>  
> QFrame::StyledPanel 
>  
>  
> QFrame::Sunken 
>  
>  
> Qt::ScrollBarAlwaysOff 
>  
>  
> true 
>  
>  
>  
>  
>  
> 32 
> 86 
> 83 
> 65 
>  
>  
>  
>  
> Courier 
> 12 
> 50 
> false 
>  
>  
>  
> false 
>  
>  
> color: rgb(0, 0, 127); 
> background-color: rgb(255, 255, 127); 
>  
>  
> QFrame::StyledPanel 
>  
>  
> QFrame::Sunken 
>  
>  
> Qt::ScrollBarAlwaysOff 
>  
>  
> true 
>  
>  
>  
>  
>  
> 114 
> 86 
> 83 
> 65 
>  
>  
>  
>  
> Courier 
> 12 
> 50 
> false 
>  
>  
>  
> false 
>  
>  
> color: rgb(0, 0, 127); 
> background-color: rgb(255, 255, 127); 
>  
>  
> QFrame::StyledPanel 
>  
>  
> QFrame::Sunken 
>  
>  
> Qt::ScrollBarAlwaysOff 
>  
>  
> true 
>  
>  
>  
>  
>  
> 196 
> 86 
> 83 
> 65 
>  
>  
>  
>  
> Courier 
> 12 
> 50 
> false 
>  
>  
>  
> false 
>  
>  
> color: rgb(0, 0, 127); 
> backgro

téléchargement python

[olivier Perchet]

   Envoye `a partir de [1]Courrier pour Windows





   [2][IMG] Garanti sans virus. [3]www.avast.com

References

   Visible links
   1. https://go.microsoft.com/fwlink/?LinkId=550986
   2. 
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
   3. 
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Chris Angelico]

On Thu, Sep 23, 2021 at 10:55 PM Mats Wichmann  wrote:
>
> On 9/22/21 10:31, Dennis Lee Bieber wrote:
>
> >   If you control both the data generation and the data consumption,
> > finding some format  ...
>
> This is really the key.  I rant at people seeming to believe that csv is
> THE data interchange format, and it's about as bad as it gets at that,
> if you have a choice.  xml is noisy but at least (potentially)
> self-documenting, and ought to be able to recover from certain errors.
> The problem with csv is that a substantial chunk of the world seems to
> live inside Excel, and so data is commonly both generated in csv so it
> can be imported into excel and generated in csv as a result of exporting
> from excel, so the parts often are *not* in your control.
>
> Sigh.

The only people who think that CSV is *the* format are people who
habitually live in spreadsheets. People who move data around the
internet, from program to program, are much more likely to assume that
JSON is the sole format. Of course, there is no single ultimate data
interchange format, but JSON is a lot closer to one than CSV is.

(Or to be more precise: any such thing as a "single ultimate data
interchange format" will be so generic that it isn't enough to define
everything. For instance, "a stream of bytes" is a universal data
interchange format, but that's not ultimately a very useful claim.)

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

Re: XML Considered Harmful

[Mats Wichmann]

On 9/22/21 10:31, Dennis Lee Bieber wrote:


If you control both the data generation and the data consumption,
finding some format  ...


This is really the key.  I rant at people seeming to believe that csv is 
THE data interchange format, and it's about as bad as it gets at that, 
if you have a choice.  xml is noisy but at least (potentially) 
self-documenting, and ought to be able to recover from certain errors. 
The problem with csv is that a substantial chunk of the world seems to 
live inside Excel, and so data is commonly both generated in csv so it 
can be imported into excel and generated in csv as a result of exporting 
from excel, so the parts often are *not* in your control.


Sigh.

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