Re: Different "look and feel" of some built-in functions
On Sat, 25 Sept 2021 at 02:16, Chris Angelico wrote: > On Sat, Sep 25, 2021 at 11:11 AM Oscar Benjamin > wrote: > > > > On Sat, 25 Sept 2021 at 02:01, Chris Angelico wrote: > >> > >> On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin > >> wrote: > >> > > >> > On Sat, 25 Sept 2021 at 00:37, Greg Ewing < > [email protected]> > >> > wrote: > >> > > I suppose they could be fiddled somehow to make it possible, but > >> > > that would be turning them into special cases that break the rules. > >> > > It would be better to provide separate functions, as was done with > >> > > sum(). > >> > > > >> > > >> > A separate union function would be good. Even in a situation where all > >> > inputs are assured to be sets the set.union method fails the base > case: > >> > > >> > >>> sets = [] > >> > >>> set.union(*sets) > >> > Traceback (most recent call last): > >> > File "", line 1, in > >> > TypeError: descriptor 'union' of 'set' object needs an argument > >> > > >> > In the case of intersection perhaps the base case should be undefined. > >> > > >> > >> Rather than calling the unbound method, why not just call it on an > >> empty set? That defines your base case as well. > >> > >> set().union(*sets) > > > > > > That is indeed what I do but it seems unnatural compared to simply > union(*sets). It shouldn't be necessary to create a redundant empty set > just to compute the union of some other sets. If there was a union function > then I don't think I would ever use the union method. > > > > Maybe, but if you start with a set, then you define the base case, and > it also is quite happy to take non-set arguments: > > >>> set().union([1,2,3], map(int, "234"), {3:"three",4:"four",5:"five"}) > {1, 2, 3, 4, 5} Actually it should be union(sets) rather than union(*sets). A more realistic example is when you need the union of sets given by something like a generator expression so it looks like: items = set().union(*(f(x) for x in stuff)) With a union function it should look like: items = union(f(x) for x in stuff) -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
On 2021-09-24 23:32:47 -, Jon Ribbens via Python-list wrote: > On 2021-09-24, Chris Angelico wrote: > > On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list > > wrote: > >> On 25/09/2021 06.59, Peter J. Holzer wrote: > >> > CSV: Good for tabular data of a single data type (strings). As soon as > >> > there's a second data type (numbers, dates, ...) you leave standard > >> > territory and are into "private agreements". > > CSV is not good for strings, as there is no one specification of how to > encode things like newlines and commas within the strings, so you may > find that your CSV data transfer fails or even silently corrupts data. Those two cases are actually pretty straightforward: Just enclose the field in quotes. Handling quotes is less standardized. I think doubling quotes is much more common than an escape character, but I've certainly seen both. But if you get down to it, the problems with CSV start at a much lower level: 1) The encoding is not defined. These days UTF-8 (with our without BOM) is pretty common, but I still regularly get files in Windows-1252 encoding and occasionally something else. 2) The record separator isn't defined. CRLF is most common, followed by LF. But just recently I got a file with CR (Does Eurostat still use some Macs with MacOS 9?) 3) The field separator isn't defined. Officially the format is known as "comma separated values", but in my neck of the woods it's actually semicolon-separated in the vast majority of cases. So even for the most simple files there are three parameters the sender and the receiver have to agree on. > >> > JSON: Has a few primitive data types (bool, number, string) and a two > >> > compound types (list, dict(string -> any)). Still missing many > >> > frequently used data types (e.g. dates) and has no standard way to > >> > denote composite types. But its simple and if it's sufficient for your > >> > needs, use it. > > JSON Schema provides a way to denote composite types. I probably wasn't clear what I meant. In XML, every element has a tag, which is basically its type. So by looking at an XML file (without reference to a schema) you can tell what each element is. And a validator can say something like "expected a 'product' or 'service' element here but found a 'person'". In JSON everything is just an object or a list. You may guess that an object with a field "product_id" is a product, but is one with "name": "Billy" a person or a piece of furniture? I'm not familiar with JSON schema (I know that it exists and I've read a tutorial or two but I've never used it in a real project), but as far as I know it doesn't change that. It describes the structure of a JSON document but it doesn't add type information to that document. So a validator can at best guess what the malformed thing it just found was supposed to be. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | [email protected] |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
Am Fri, Sep 24, 2021 at 08:59:23PM +0200 schrieb Peter J. Holzer: > JSON: Has a few primitive data types (bool, number, string) and a two > compound types (list, dict(string -> any)). Still missing many > frequently used data types (e.g. dates) But that (dates) at least has a well-known mapping to string, which makes it usable within JSON. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
EuroPython Society: General Assembly 2021
As last year, we are holding the General Assembly (GA) of the EuroPython Society (EPS) online for this year. General Assembly In accordance with our bylaws, we are calling for the EuroPython Society General Assembly to be held on Sunday, October 10th 2020, from 19:00 - 21:00 CEST. We will use a Zoom meeting to hold the event and send around the URL closer to the event. All EPS members are welcome to join and vote at the meeting. Please be aware that we cannot allow non-EPS members to join, as we often do at the in-person GAs we hold at the conference, since we would then not be able to control access to the Zoom call. Board Nominations - As every year, we will vote in a new board. We have already sent out the list of board nominations in a separate blog post on 2021-09-23. Please see that post for details on the candidates and the nomination process. Motions by the Members -- EuroPython Society Members can propose motions to be put forward and voted on at the General Assembly. If you want to put forward a motion, please send this to [email protected] no later than Sunday, 2021-10-03, so that we can add them to the agenda. The bylaws require that any such motions be announced no later than 5 days before the GA and we will need time to clarify details and prepare the agenda. Agenda -- We will publish the agenda with all motions put forward by the board and the members on Tuesday, 2020-10-05. The agenda will follow the template set out in our bylaws under section 8. https://www.europython-society.org/bylaws Reports --- All reports for the GA will be published on Friday, 2020-10-08, to give the members enough time to read them and prepare questions. We’ll then answer any questions at the GA. 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://www.europython-society.org/europython-society-general-assembly-2021/ Tweet: https://twitter.com/europythons/status/1441788705514065921 Thanks, -- EuroPython Society https://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Different "look and feel" of some built-in functions
Stefan Ram wrote at 2021-9-24 16:48 GMT: >"Dieter Maurer" writes: >>A list is ordered. Therefore, it is important where >>in this order an element is added. Thus, for a list, >>`append` is a better name than `add` -- because it already >>tells us in the name where it adds the new element. > > In a collection of texts, which is not large but mixed from > many different fields and genres, I find (using a Python > script, of course) eight hits for "added to the list" : > >|s and rock n roll can be added to the list. As - Taylor, 2012 >| of opinion was probably added to the list tow - from a dictionary >|gg and his wife might be added to the list of - Sir Walter Scott >|ships when your name was added to the list. In - Percy Bysshe Shelley >|em that wealth should be added to the list. No - Henry >|n was discovered and was added to the list of - from a dictionary >|nd said his name must be added to the list, or - Mark Twain While a list is ordered, applications using a list may not be interested in the particular order and thus just speak of "add to the list" rather than "append to the list". Nevertheless, I find the name `append` far better than `add` for the list type - because it describes better what it is doing. I am a big fan of "speaking names". > . There was no hit for "appended to the list". > > When one says "add something to a list", it is usually understood > that one adds it at the /end/. In the case of traditional written > lists it is not possible in any other way. Really? Prepending should be as possible as appending (if one disregards implementation details). -- Dieter -- https://mail.python.org/mailman/listinfo/python-list
Re: Different "look and feel" of some built-in functions
On Sun, Sep 26, 2021 at 2:27 AM Dieter Maurer wrote: > > Stefan Ram wrote at 2021-9-24 16:48 GMT: > >"Dieter Maurer" writes: > >>A list is ordered. Therefore, it is important where > >>in this order an element is added. Thus, for a list, > >>`append` is a better name than `add` -- because it already > >>tells us in the name where it adds the new element. > > > > In a collection of texts, which is not large but mixed from > > many different fields and genres, I find (using a Python > > script, of course) eight hits for "added to the list" : > > > >|s and rock n roll can be added to the list. As - Taylor, 2012 > >| of opinion was probably added to the list tow - from a dictionary > >|gg and his wife might be added to the list of - Sir Walter Scott > >|ships when your name was added to the list. In - Percy Bysshe Shelley > >|em that wealth should be added to the list. No - Henry > >|n was discovered and was added to the list of - from a dictionary > >|nd said his name must be added to the list, or - Mark Twain > > While a list is ordered, > applications using a list may not be interested in the particular > order and thus just speak of "add to the list" > rather than "append to the list". > > Nevertheless, I find the name `append` far better than `add` for > the list type - because it describes better what it is doing. > I am a big fan of "speaking names". Yeah, so I would say it makes perfectly good sense to do something like this: def add_customer(...): cust = ... customers.append(cust) where it's "add" in your application, but "append" in Python's list object. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Different "look and feel" of some built-in functions
Steve Keller wrote at 2021-9-25 00:15 +0200:
>"Dieter Maurer" writes:
>
>> Steve Keller wrote at 2021-9-24 11:48 +0200:
>> >Why do some built-in Python functions feel so differently:
>>
>> Because the typical use cases are different
>>
>> [...]
>>
>> >while other functions like set.union() and set.intersection() work on
>> >a list of arguments but not on a sequence:
>> >
>> >set.intersection({1,2,3}, {3,4,5})
>>
>> Those operations are typically applied to a small number
>> of operands. You would need to build an iterator in that
>> case should the functions only accept iterators.
>
>In my experience I need intersection and union on a list of sets, set
>of sets or a map() returning sets much more often. E.g. in some
>mathematical problems, and in automaton theory (IIRC, computing of LR
>or LALR sets, converting NFA to DFA, minimizing DFA), many graph
>algorithms traversing the nodes (shortest path, ...), and so on).
I, too, occasionally work with set operations on many operands
-- in the context of `Zope`, more precisely `BTrees`.
There, I have both `union(op1, op2)` and `multiunion(iterator)`
(`multiunion` is there primarily for efficiency reasons).
I you often have operations on large sets of operands,
you could define corresponding "convernience functions".
--
Dieter
--
https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
On 2021-09-25, Peter J. Holzer wrote: > On 2021-09-24 23:32:47 -, Jon Ribbens via Python-list wrote: >> JSON Schema provides a way to denote composite types. > > I probably wasn't clear what I meant. In XML, every element has a tag, > which is basically its type. So by looking at an XML file (without > reference to a schema) you can tell what each element is. And a > validator can say something like "expected a 'product' or 'service' > element here but found a 'person'". > > In JSON everything is just an object or a list. You may guess that an > object with a field "product_id" is a product, but is one with "name": > "Billy" a person or a piece of furniture? > > I'm not familiar with JSON schema (I know that it exists and I've read a > tutorial or two but I've never used it in a real project), but as far as > I know it doesn't change that. It describes the structure of a JSON > document but it doesn't add type information to that document. So a > validator can at best guess what the malformed thing it just found was > supposed to be. JSON Schema absolutely does change that. You can create named types and specify where they may appear in the document. With a well-defined schema you do not need to make any guesses about what type something is. -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
On 21/09/2021 13.12, Michael F. Stemper wrote:
If XML is not the way to package data, what is the recommended
approach?
Well, there have been a lot of ideas put forth on this thread,
many more than I expected. I'd like to thank everyone who
took the time to contribute.
Most of the reasons given for avoiding XML appear to be along
the lines of "XML has all of these different options that it
supports."
However, it seems that I could ignore 99% of those things and
just use a teeny subset of its capabilities. For instance, if
I modeled a fuel like this:
ton
21.96
18.2
and a generating unit like this:
why would the fact that I could have chosen, instead, to model
the unit of measure as an attribute of the fuel, or its name
as a sub-element matter? Once the modeling decision has been
made, all of the decisions that might have been would seem to
be irrelevant.
Some years back, IEC's TC57 came up with CIM[1]. This nailed down
a lot of decisions. The fact that other decisions could have been
made doesn't seem to keep utilities from going forward with it as
an enterprise-wide data model.
My current interests are not anywhere so expansive, but it seems
that the situations are at least similar:
1. Look at an endless range of options for a data model.
2. Pick one.
3. Run with it.
To clearly state my (revised) question:
Why does the existence of XML's many options cause a problem
for my use case?
Other reactions:
Somebody pointed out that some approaches would require that I
climb a learning curve. That's appreciated, although learning
new things is always good.
NestedText looks cool, and a lot like YAML. Having not gotten
around to playing with YAML yet, I was surprised to learn that it
tries to guess data types. This sounds as if it could lead to the
same type of problems that led to the names of some genes being
turned into dates.
It was suggested that I use an RDBMS, such as sqlite3, for the
input data. I've used sqlite3 for real-time data exchange between
concurrently-running programs. However, I don't see syntax like:
sqlite> INSERT INTO Fuels
...> (name,uom,price,heat_content)
...> VALUES ("Montana Sub-Bituminous", "ton", 21.96, 13.65);
as being nearly as readable as the XML that I've sketched above.
Yeah, I could write a program to do this, but that doesn't really
change anything, since I'd still need to get the data into the
program.
(Changing a value would be even worse, requiring the dreaded
UPDATE INTO statement, instead of five seconds in vi.)
Many of the problems listed for CSV, which come from its lack of
standardization, seem similar to those given for XML. "Commas
or tabs?" "How are new-lines represented?" If I was to use CSV,
I'd be able to just pick answers. However, fitting hierarchical
data into rows/columns just seems wrong, so I doubt that I'll
end up going that way.
As far as disambiguating authors, I believe that most journals
are now expecting an ORCID[2] (which doesn't help with papers
published before that came around).
As far as use of XML to store program state, I wouldn't ever
consider that. As noted above, I've used an RDBMS to do so.
It handles all of the concurrency issues for me. The current use
case is specifically for raw, static input.
Fascinating to find out that XML was originally designed to
mark up text, especially legal text.
It was nice to be reminded of what Matt Parker looked like when
he had hair.
[1]
[2]
Could not initilalize crash reporting DB
I have a script that chooses a paragraph at random from a text file then uses that paragraph to generate and send an email message. It's set up to run on Windows 7 startup. It has run without issue more than 400 times. Recently two consecutive runs produced the following messages... Could not initialize crash reporting DB Cannot init crashpad with status: CRASHPAD_INIT_DB_ERROR Despite the messages the script otherwise ran as expected. Google searches turned up nothing useful. I was hoping that maybe someone here could tell me what these messages mean. -- https://mail.python.org/mailman/listinfo/python-list
RE: XML Considered Harmful
Michael, I don't care what you choose. Whatever works is fine for an internal use. But is the data scheme you share representative of your actual application? >From what I see below, unless the number of "point" variables is not always exactly four, the application might be handled well by any format that handles rectangular data, perhaps even CSV. You show a I mean anything like a data.frame can contain data columns like p1,p2,p3,p4 and a categorical one like IHRcurve_name. Or do you have a need for more variability such as an undetermined number of similar units in ways that might require more flexibility or be more efficient done another way? MOST of the discussion I am seeing here seems peripheral to getting you what you need for your situation and may require a learning curve to learn to use properly. Are you planning on worrying about how to ship your data encrypted, for example? Any file format you use for storage can presumably be encrypted and send and decrypted if that matters. So, yes, from an abstract standpoint we can discuss the merits of various approaches. If it matters that humans can deal with your data in a file or that it be able to be imported into a program like EXCEL, those are considerations. But if not, there are quite a few relatively binary formats where your program can save a snapshot of the data into a file and read it back in next time. I often do that in another language that lets me share variable including nested components such as the complex structures that come out of a statistical analysis or the components needed to make one or more graphs later. If you write the program that creates the darn things as well as the one that later reads them back in, you can do what you want. Or, did I miss something and others have already produced the data using other tools, in which case you have to read it in at least once/ -Original Message- From: Python-list On Behalf Of Michael F. Stemper Sent: Saturday, September 25, 2021 4:20 PM To: [email protected] Subject: Re: XML Considered Harmful On 21/09/2021 13.12, Michael F. Stemper wrote: > If XML is not the way to package data, what is the recommended > approach? Well, there have been a lot of ideas put forth on this thread, many more than I expected. I'd like to thank everyone who took the time to contribute. Most of the reasons given for avoiding XML appear to be along the lines of "XML has all of these different options that it supports." However, it seems that I could ignore 99% of those things and just use a teeny subset of its capabilities. For instance, if I modeled a fuel like this: ton 21.96 18.2 and a generating unit like this: why would the fact that I could have chosen, instead, to model the unit of measure as an attribute of the fuel, or its name as a sub-element matter? Once the modeling decision has been made, all of the decisions that might have been would seem to be irrelevant. Some years back, IEC's TC57 came up with CIM[1]. This nailed down a lot of decisions. The fact that other decisions could have been made doesn't seem to keep utilities from going forward with it as an enterprise-wide data model. My current interests are not anywhere so expansive, but it seems that the situations are at least similar: 1. Look at an endless range of options for a data model. 2. Pick one. 3. Run with it. To clearly state my (revised) question: Why does the existence of XML's many options cause a problem for my use case? Other reactions: Somebody pointed out that some approaches would require that I climb a learning curve. That's appreciated, although learning new things is always good. NestedText looks cool, and a lot like YAML. Having not gotten around to playing with YAML yet, I was surprised to learn that it tries to guess data types. This sounds as if it could lead to the same type of problems that led to the names of some genes being turned into dates. It was suggested that I use an RDBMS, such as sqlite3, for the input data. I've used sqlite3 for real-time data exchange between concurrently-running programs. However, I don't see syntax like: sqlite> INSERT INTO Fuels ...> (name,uom,price,heat_content) ...> VALUES ("Montana Sub-Bituminous", "ton", 21.96, 13.65); as being nearly as readable as the XML that I've sketched above. Yeah, I could write a program to do this, but that doesn't really change anything, since I'd still need to get the data into the program. (Changing a value would be even worse, requiring the dreaded UPDATE INTO statement, instead of five seconds in vi.) Many of the problems listed for CSV, which come from its lack of standardization, seem similar to those given for XML. "Commas or tabs?" "How are new-lines represented?" If I was to use CSV, I'd be able to just pick answers. However, fitting hierarchical data into rows/columns
Re: XML Considered Harmful
On 2021-09-25 at 15:20:19 -0500, "Michael F. Stemper" wrote: > ... For instance, if > I modeled a fuel like this: > > > ton > 21.96 > 18.2 > > > and a generating unit like this: > > > > > > > > > > > > > > > > > why would the fact that I could have chosen, instead, to model > the unit of measure as an attribute of the fuel, or its name > as a sub-element matter? Once the modeling decision has been > made, all of the decisions that might have been would seem to > be irrelevant. Disclaimer: I am not a big XML fan, for a number of reasons already stated in this thread. That said, please do include units in elements like heat_content, whether or not it's Joules/kilogram/K, and price, even if is the local currency in the only country to which your data applies. If there's a standard for your industry, or your company, or on some other level, then at least document what it is and that you're using it, so that the next person (which may be you a year from now) doesn't have to guess. You also never know when someone else on the other side of the planet will notice your work and try to duplicate it and/or update it (again, even if it's you). The fewer assumptions that person has to make, the better. -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
On 26/09/2021 10.07, Stefan Ram wrote: > "Michael F. Stemper" writes: >> fitting hierarchical >> data into rows/columns just seems wrong > > There were hierarchical database management systems like > IMS by IBM based on that point of view. Today, almost all > hierarchical data that is stored in databases is stored > in relational databases. Maybe, the relational model has > proven superior to the hierarchical data model after all. Back in the days of mainframes (and when the Flintstones was 'filmed before a live studio audience') hierarchical DBs were considerably faster than RDBMS. Because of this, we used to take a daily 'snapshot' of the transaction DBs (in IMS) and make a 'copy' as DB2 relational DBs, which were (supposedly) used for MIS (Management Information Systems - as distinct from TPS (Transaction Processing Systems)). These days RDBMS are (a lot!) faster - much of which would be better expressed as: the hardware these days is a lot faster. Therefore an RDBMS is sufficiently responsive, and we no-longer need to maintain separate, 'parallel' systems (and multiple mainframes)! Cue: NoSQL justifications... Today's best example of an hierarchical DB is probably LDAP. It is most commonly used within the 'directory' of communications systems, eg email. Such waters muddied considerably by MSFT's attempts to 'improve' international 'standards' and integrate AD with Exchange (so don't go there!). There have been some well-engineered systems based on LDAP, eg organisational/personnel and part/component break-downs. That said, unless looking at something such as just-mentioned, overlaying hierarchy onto 3NF and using an RDBMS would be my first thought - but because of the recursive JOINs, I recommend something more capable than SQLite. -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
On 26/09/2021 10.48, [email protected] wrote: > On 2021-09-25 at 15:20:19 -0500, > "Michael F. Stemper" wrote: > >> ... For instance, if >> I modeled a fuel like this: >> >> >> ton >> 21.96 >> 18.2 >> ... > Disclaimer: I am not a big XML fan, for a number of reasons > already stated in this thread. > > That said, please do include units in elements like heat_content, > whether or not it's Joules/kilogram/K, and price, even if is the > local currency in the only country to which your data applies. > If there's a standard for your industry, or your company, or on > some other level, then at least document what it is and that > you're using it, so that the next person (which may be you a > year from now) doesn't have to guess. +1 *always* add unit attributes -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Posts from gmane no longer allowed?
I've been reading (and posting to) this list for many years by pointing an NNTP client at news://gmane.comp.python.general. Sometime in the past few days posts started being refused: You have tried posting to gmane.comp.python.general, which is a unidirectional mailing list. Gmane can therefore not send this message to that mailing list. Was this a change made by the mailing list admins? If so, is it permanent? [Trying to send a plaintext e-mail via Gmail, but not sure if it's working.] -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
In comp.lang.python, Chris Angelico wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> 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
His spreadsheet is a PPM file, not a JPEG. You can tell because all of
the cells are the same size.
He also ignores vector graphics when considering digital images. Often
they are rendered in what he calls "spreadsheets" but not always. I have
a Vectrex, for example.
Elijah
--
then there's typewriter art with non-square "pixels"
--
https://mail.python.org/mailman/listinfo/python-list
Re: XML Considered Harmful
On Sun, Sep 26, 2021 at 9:09 AM Eli the Bearded <*@eli.users.panix.com> wrote:
>
> In comp.lang.python, Chris Angelico wrote:
> > Eli the Bearded <*@eli.users.panix.com> wrote:
> >> 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
>
> His spreadsheet is a PPM file, not a JPEG. You can tell because all of
> the cells are the same size.
>
> He also ignores vector graphics when considering digital images. Often
> they are rendered in what he calls "spreadsheets" but not always. I have
> a Vectrex, for example.
>
> Elijah
> --
> then there's typewriter art with non-square "pixels"
Ah, I remember playing around with line printer art. We mostly had
Epsons and IBMs that did have some measure of graphical capabilities,
but it was WAY faster to print text, so we sometimes did things the
hacky and elegant way instead.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
