Re: XML Considered Harmful

[Peter J. Holzer]

On 2021-09-27 21:01:04 -0400, Avi Gross via Python-list wrote:
> You keep talking about generators, though. If the generators are outside of
> your program, then yes, you need to read in whatever they produce.

As I understood it, the "generators" don't generate the data, they are
the subject of the data: Devices that generate electricity by burning
fuel and he's modelling some aspect of their operation. Maybe efficiency
or power output or something like that (I tried to search for "IHR
curve", but couldn't find anything).

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

Re: XML Considered Harmful

[dn via Python-list]

On 25/09/2021 11.26, David L Neil via Python-list wrote:
> On 25/09/2021 11.00, Chris Angelico wrote:
> 
>> Invented because there weren't enough markup languages, so we needed another?
> 
> Anything You Can Do I Can Do Better
> https://www.youtube.com/watch?v=_UB1YAsPD6U


Article (rather brief) introducing YAML, of possible interest:
https://opensource.com/article/21/9/intro-yaml

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

Re: XML Considered Harmful

[Michael F. Stemper]

On 27/09/2021 20.01, Avi Gross wrote:

Michael,

Given your further explanation, indeed reading varying numbers of points in
using a CSV is not valid, albeit someone might just make N columns (maybe a
few more than 7) to handle a hopefully worst case. Definitely it makes more
sense to read in a list or other data structure.

You keep talking about generators, though. If the generators are outside of
your program, then yes, you need to read in whatever they produce.


My original post (which is as the snows of yesteryear) made explicit the
fact that when I refer to a generator, I'm talking about something made
from tons of iron and copper that is oil-filled and rotates at 1800 rpm.
(In most of the world other than North America, they rotate at 1500 rpm.)

Nothing to do with the similarly-named python construct. Sorry for the
ambiguity.


But if
your data generator is within your own program,


The data is created in my mind, and approximates typical physical
characteristics of real generators.


My impression is you may not be using your set of data points for any other
purposes except when ready to draw a spline.


Nope, the points give a piecewise-linear curve, and values between two
consecutive points are found by linear interpolation. It's industry
standard practice.



Can I just ask if by a generator, you do NOT mean the more typical use of
"generator" as used in python


Nope; I mean something that weighs 500 tons and rotates, producing
electrical energy.


  Do you mean something that creates
realistic test cases to simulate a real-word scenario?


The thing that creates realistic test cases is my brain.


  These often can
create everything at once and often based on random numbers.


I have written such, but not in the last thirty years. At that time, I
needed to make up data for fifty or one hundred generators, along with
tie lines and loads.

What I'm working on now only needs a handful of generators at a time;
just enough to test my hypothesis. (Theoretically, I could get by with
two, but that offends my engineering sensibilities.)


create everything at once and often based on random numbers. Again, if you
have or build such code, it is not clear it needs to be written to disk and
then read back.


Well, I could continue to hard-code the data into one of the test
programs, but that would mean that every time that I wanted to look
at a different scenario, I'd need to modify a program. And when I
discover anomalous behavior, I'd need to copy the hard-coded data
into another program.

Having the data in a separate file means that I can provide a function
to read that file and return a list of generators (or fuels) to a
program. Multiple test cases are then just multiple files, all of which
are available to multiple programs.


  You may of course want to save it, perhaps as a log, to show
what your program was working on.


That's another benefit of having the data in external files.

--
Michael F. Stemper
A preposition is something you should never end a sentence with.
--
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Michael F. Stemper]

On 28/09/2021 02.25, Peter J. Holzer wrote:

On 2021-09-27 21:01:04 -0400, Avi Gross via Python-list wrote:

You keep talking about generators, though. If the generators are outside of
your program, then yes, you need to read in whatever they produce.


As I understood it, the "generators" don't generate the data, they are
the subject of the data: Devices that generate electricity by burning
fuel and he's modelling some aspect of their operation. Maybe efficiency
or power output or something like that (I tried to search for "IHR
curve", but couldn't find anything).


If you expand "IHR curve" to "incremental heat rate curve", you'll get
better results. When power engineers talk, we say the first, when we
publish papers, we write the second.

If you want to see the bigger picture, search on "Economic Dispatch".
In fact, doing so points me to something written by a guy I worked with
back in the 1980s:


Slide 3 even shows a piecewise-linear curve.

--
Michael F. Stemper
A preposition is something you should never end a sentence with.
--
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Michael F. Stemper]

On 28/09/2021 10.53, Stefan Ram wrote:

"Michael F. Stemper"  writes:

Well, I could continue to hard-code the data into one of the test
programs


   One can employ a gradual path from a program with hardcoded
   data to an entity sharable by different programs.

   When I am hurried to rush to a working program, I often
   end up with code that contains configuration data spread
   (interspersed) all over the code. For example:



   1st step: give a name to all the config data:



   2nd: move all config data to the top of the source code,
   directly after all the import statements:



   3rd: move all config data to a separate "config.py" module:

import ...
import config
...

...
open( config.project_directory + "data.txt" )
...


but that would mean that every time that I wanted to look
at a different scenario, I'd need to modify a program.


   Now you just have to modify "config.py" - clearly separated
   from the (rest of the) "program".


Well, that doesn't really address what format to store the data
in. I was going to write a module that would read data from an
XML file:

import EDXML
gens = EDXML.GeneratorsFromXML( "gendata1.xml" )
fuels = EDXML.FuelsFromXML( "fueldata3.xml" )

(Of course, I'd really get the file names from command-line arguments.)

Then I read a web page that suggested use of XML was a poor idea,
so I posted here asking for a clarification and alternate suggestions.

One suggestion was that I use YAML, in which case, I'd write:

import EDfromYAML
gens = EDfromYAML( "gendata1.yaml" )
fuels = EDXML.FuelsFromYAML( "fueldata3.yaml" )


And when I discover anomalous behavior, I'd need to copy the
hard-coded data into another program.


   Now you just have to import "config.py" from the other program.


This sounds like a suggestion that I hard-code the data into a
module. I suppose that I could have half-a-dozen modules with
different data sets and ln them as required:

$ rm GenData.py* FuelData.py*
$ ln gendata1.py GenData.py
$ ln fueldata3.py FuelData.py

It seems to me that a more thorough separation of code and data
might be useful.

--
Michael F. Stemper
The name of the story is "A Sound of Thunder".
It was written by Ray Bradbury. You're welcome.
--
https://mail.python.org/mailman/listinfo/python-list

RE: XML Considered Harmful

[Avi Gross via Python-list]

I replied to Michael privately but am intrigued by his words here:

"The thing that creates realistic test cases is my brain."

I consider extensions to my brain to include using a language like Python on
my computer and in particular, to take a model I think of and instantiate
it. Lots of people have shared modules that can be tweaked to do all kinds
of simulations using a skeleton you provide that guides random number usage.
Some will generate lots of those and stare at them and use their brain to
further narrow it down to realistic ones. For example, in designing say a
car with characteristics like miles per gallon should randomly range between
10 and 100 while engine size ranges from this to that and so on, it may turn
out that large engines don't go well with large number for miles per gallon.

I have worked on projects where a set of guides then created hundreds of
thousands of fairly realistic scenarios using every combination of an
assortment of categorical variables and the rest of the program sliced and
diced the results and did all kinds of statistical calculations and then
generated all kinds of graphs. There was no real data but there was a
generator that was based on the kinds of distributions previously published
in the field that helped guide parameters to be somewhat realistic.

In your case, I understand you will decide how to do it and just note you
used language with multiple meanings that misled a few of us into thinking
you either had a python function in mind using one of several ways Python
refers to as generators, such as one that efficiently yields the next prime
number when asked. Clearly your explanation now shows you plan on making a
handful of data sets by hand using an editor like vi. Fair enough. No need
to write complex software if your mind is easily able to just make half a
dozen variations in files. And, frankly, not sure why you need XML or much
of anything. It obviously depends on how much you are working with and how
variable. For simpler things, you can hard-code your data structure directly
into your program, run an analysis, change the variables to your second
simulation and repeat.

I am afraid that I, like a few others here, assumed a more abstract and much
more complex need to be addressed. Yours may be complex in other parts but
may need nothing much for the part we are talking about. It sounds like you
do want something easier to create while editing.

-Original Message-
From: Python-list  On
Behalf Of Michael F. Stemper
Sent: Tuesday, September 28, 2021 11:38 AM
To: python-list@python.org
Subject: Re: XML Considered Harmful

On 27/09/2021 20.01, Avi Gross wrote:
> Michael,
> 
> Given your further explanation, indeed reading varying numbers of 
> points in using a CSV is not valid, albeit someone might just make N 
> columns (maybe a few more than 7) to handle a hopefully worst case. 
> Definitely it makes more sense to read in a list or other data structure.
> 
> You keep talking about generators, though. If the generators are 
> outside of your program, then yes, you need to read in whatever they
produce.

My original post (which is as the snows of yesteryear) made explicit the
fact that when I refer to a generator, I'm talking about something made from
tons of iron and copper that is oil-filled and rotates at 1800 rpm.
(In most of the world other than North America, they rotate at 1500 rpm.)

Nothing to do with the similarly-named python construct. Sorry for the
ambiguity.

> But if
> your data generator is within your own program,

The data is created in my mind, and approximates typical physical
characteristics of real generators.

> My impression is you may not be using your set of data points for any 
> other purposes except when ready to draw a spline.

Nope, the points give a piecewise-linear curve, and values between two
consecutive points are found by linear interpolation. It's industry standard
practice.


> Can I just ask if by a generator, you do NOT mean the more typical use 
> of "generator" as used in python

Nope; I mean something that weighs 500 tons and rotates, producing
electrical energy.

>   Do you mean something that creates
> realistic test cases to simulate a real-word scenario?

The thing that creates realistic test cases is my brain.

>   These often can
> create everything at once and often based on random numbers.

I have written such, but not in the last thirty years. At that time, I
needed to make up data for fifty or one hundred generators, along with tie
lines and loads.

What I'm working on now only needs a handful of generators at a time; just
enough to test my hypothesis. (Theoretically, I could get by with two, but
that offends my engineering sensibilities.)

> create everything at once and often based on random numbers. Again, if 
> you have or build such code, it is not clear it needs to be written to 
> disk and then read back.

Well, I could continue to hard-code the data into one of the test programs,
but tha

RE: XML Considered Harmful

[Avi Gross via Python-list]

Well, Michael, if you want to go back to the eighties, and people you worked
with, I did my Thesis with a professor who later had an Erdős number of 1!
Too bad I never got around to publishing something with him or I could have
been a 2!

But that work, being so long ago, was not in Python but mainly in PASCAL.

Ah the good old days.

-Original Message-
From: Python-list  On
Behalf Of Michael F. Stemper
Sent: Tuesday, September 28, 2021 11:45 AM
To: python-list@python.org
Subject: Re: XML Considered Harmful

On 28/09/2021 02.25, Peter J. Holzer wrote:
> On 2021-09-27 21:01:04 -0400, Avi Gross via Python-list wrote:
>> You keep talking about generators, though. If the generators are 
>> outside of your program, then yes, you need to read in whatever they
produce.
> 
> As I understood it, the "generators" don't generate the data, they are 
> the subject of the data: Devices that generate electricity by burning 
> fuel and he's modelling some aspect of their operation. Maybe 
> efficiency or power output or something like that (I tried to search 
> for "IHR curve", but couldn't find anything).

If you expand "IHR curve" to "incremental heat rate curve", you'll get
better results. When power engineers talk, we say the first, when we publish
papers, we write the second.

If you want to see the bigger picture, search on "Economic Dispatch".
In fact, doing so points me to something written by a guy I worked with back
in the 1980s:


Slide 3 even shows a piecewise-linear curve.

--
Michael F. Stemper
A preposition is something you should never end a sentence with.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: XML Considered Harmful

[Karsten Hilbert]

Am Tue, Sep 28, 2021 at 12:53:49PM -0500 schrieb Michael F. Stemper:

> This sounds like a suggestion that I hard-code the data into a
> module. I suppose that I could have half-a-dozen modules with
> different data sets and ln them as required:
>
> $ rm GenData.py* FuelData.py*
> $ ln gendata1.py GenData.py
> $ ln fueldata3.py FuelData.py

vi data.py

generators = {}
generators['name1'] = {'fuel': ..., ...}
generators['name2'] = {...}
...

vi simulation.py

import sys
import data

generator = data.generators[sys.argv[1]]
run_simulation(generator)

or some such ?

Your data "format" is ... Python code.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Michael F. Stemper]

On 28/09/2021 13.27, Avi Gross wrote:

Well, Michael, if you want to go back to the eighties, and people you worked
with, I did my Thesis with a professor who later had an Erdős number of 1!
Too bad I never got around to publishing something with him or I could have
been a 2!


Lucky you. If a paper that a friend of mine is submitting to various
journals gets accepted by one of them, I'll end up with a 4 or 5 through
him. However, as the months pass, it's looking more like mine will end
up NaN.

--
Michael F. Stemper
Isaiah 58:6-7
--
https://mail.python.org/mailman/listinfo/python-list

RE: XML Considered Harmful

[Avi Gross via Python-list]

Not lucky at all, Michael. The problem is he published a number of things
with Paul Erdős a few years after I got my degrees and went to Bell
laboratories. I never met Erdős but he was prolific and had 507 people
publish with him as co-authors. I would have loved to as I also speak
languages he spoke including Hungarian and Math.

Well, time to get back to something remotely about Python. Is there any
concept of a Rossum Number where anyone who worked directly with Guido Van
Rossum is a 1 (or True or truthy) and ...

Hey I just realized my Berners-Lee number might be 1 but it was so long ago
we worked on what Hypertext should look like, ...

-Original Message-
From: Python-list  On
Behalf Of Michael F. Stemper
Sent: Tuesday, September 28, 2021 2:41 PM
To: python-list@python.org
Subject: Re: XML Considered Harmful

On 28/09/2021 13.27, Avi Gross wrote:
> Well, Michael, if you want to go back to the eighties, and people you 
> worked with, I did my Thesis with a professor who later had an Erdős
number of 1!
> Too bad I never got around to publishing something with him or I could 
> have been a 2!

Lucky you. If a paper that a friend of mine is submitting to various
journals gets accepted by one of them, I'll end up with a 4 or 5 through
him. However, as the months pass, it's looking more like mine will end up
NaN.

--
Michael F. Stemper
Isaiah 58:6-7
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: XML Considered Harmful

[Chris Angelico]

On Wed, Sep 29, 2021 at 8:00 AM Stefan Ram  wrote:
>   JSON is a kind of a subset of JavaScript for JavaScript
>   programmers. In Python, we can use JSON too, or we can
>   use Python itself.
>
>   When some external requirement to use a data exchange
>   notation like JSON should appear, one can still "translate"
>   such Python modules to JSON. This path is not blocked.

JSON exists as a transport mechanism because it is restricted and
can't contain malicious code. A Python equivalent would be
ast.literal_eval - a strict subset of the language but restricted for
safety. For trusted code, yes, straight code can be used.

(And ast.literal_eval, unlike JSON, can handle comments.)

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

OT: AttributeError

[dn via Python-list]

On 29/09/2021 10.50, Stefan Ram wrote:
>   (For Python programmers who have watched "Game of Thrones".)
> 
> |>>> class girl:
> |... pass
> |...
> |>>> girl = girl()
> |>>> print( girl.name )
> |Traceback (most recent call last):
> |  File "", line 1, in 
> |AttributeError: A girl has no name.


For oldies, who remember the musical "South Pacific" (to say nothing of
calculating addresses on a backing-store):
sing "on a clear disk, you can seek forever..."

For C programmers who are fans of pirate stories:
long John # Silver

For those of us who remember/can compute in binary, octal, hex, or
decimal as-needed:
Why do programmers confuse All Hallows'/Halloween for Christmas Day?

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

Re: OT: AttributeError

[2QdxY4RzWzUUiLuE]

On 2021-09-29 at 11:38:22 +1300,
dn via Python-list  wrote:

> For those of us who remember/can compute in binary, octal, hex, or
> decimal as-needed:
> Why do programmers confuse All Hallows'/Halloween for Christmas Day?

That one is also very old.  (Yes, I know the answer.  No, I will not
spoil it for those who might not.)  What do I have to do to gain the
insight necessary to have discovered that question and answer on my own?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: AttributeError

[Chris Angelico]

On Wed, Sep 29, 2021 at 9:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-09-29 at 11:38:22 +1300,
> dn via Python-list  wrote:
>
> > For those of us who remember/can compute in binary, octal, hex, or
> > decimal as-needed:
> > Why do programmers confuse All Hallows'/Halloween for Christmas Day?
>
> That one is also very old.  (Yes, I know the answer.  No, I will not
> spoil it for those who might not.)  What do I have to do to gain the
> insight necessary to have discovered that question and answer on my own?

You'd have to be highly familiar with numbers in different notations,
to the extent that you automatically read 65 and 0x41 as the same
number. Or, even better, to be able to read off a hex dump and see E8
03 and instantly read it as "1,000 little-endian".

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

Re: XML Considered Harmful

[Greg Ewing]

On 29/09/21 4:37 am, Michael F. Stemper wrote:

I'm talking about something made
from tons of iron and copper that is oil-filled and rotates at 1800 rpm.


To avoid confusion, we should rename them "electricity comprehensions".

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

Re: XML Considered Harmful

[dn via Python-list]

On 29/09/2021 06.53, Michael F. Stemper wrote:
> On 28/09/2021 10.53, Stefan Ram wrote:
>> "Michael F. Stemper"  writes:
>>> Well, I could continue to hard-code the data into one of the test
>>> programs
>>
>>    One can employ a gradual path from a program with hardcoded
>>    data to an entity sharable by different programs.
>>
>>    When I am hurried to rush to a working program, I often
>>    end up with code that contains configuration data spread
>>    (interspersed) all over the code. For example:
> 
>>    1st step: give a name to all the config data:
> 
>>    2nd: move all config data to the top of the source code,
>>    directly after all the import statements:
> 
>>    3rd: move all config data to a separate "config.py" module:
>>
>> import ...
>> import config
>> ...
>>
>> ...
>> open( config.project_directory + "data.txt" )
>> ...
>>
>>> but that would mean that every time that I wanted to look
>>> at a different scenario, I'd need to modify a program.
>>
>>    Now you just have to modify "config.py" - clearly separated
>>    from the (rest of the) "program".
> 
> Well, that doesn't really address what format to store the data
> in. I was going to write a module that would read data from an
> XML file:
> 
> import EDXML
> gens = EDXML.GeneratorsFromXML( "gendata1.xml" )
> fuels = EDXML.FuelsFromXML( "fueldata3.xml" )
> 
> (Of course, I'd really get the file names from command-line arguments.)
> 
> Then I read a web page that suggested use of XML was a poor idea,
> so I posted here asking for a clarification and alternate suggestions.
> 
> One suggestion was that I use YAML, in which case, I'd write:
> 
> import EDfromYAML
> gens = EDfromYAML( "gendata1.yaml" )
> fuels = EDXML.FuelsFromYAML( "fueldata3.yaml" )
> 
>>> And when I discover anomalous behavior, I'd need to copy the
>>> hard-coded data into another program.
>>
>>    Now you just have to import "config.py" from the other program.
> 
> This sounds like a suggestion that I hard-code the data into a
> module. I suppose that I could have half-a-dozen modules with
> different data sets and ln them as required:
> 
> $ rm GenData.py* FuelData.py*
> $ ln gendata1.py GenData.py
> $ ln fueldata3.py FuelData.py
> 
> It seems to me that a more thorough separation of code and data
> might be useful.


Dear Michael,

May I suggest that you are right - and that he is right!
(which is a polite way of saying, also, that both are wrong. Oops!)
(with any and all due apologies)


There are likely cross-purposes here.


I am interpreting various clues, from throughout the thread (from when
the snowflakes were still falling!) that you and I were trained
way-back: to first consider the problem, state the requirements
("hypothesis" in Scientific Method), and work our way to a solution
on-paper. Only when we had a complete 'working solution', did we step up
to the machine (quite possibly a Card Punch, cf a 'computer') and
implement.

Also, that we thought in terms of a clear distinction between
"program[me]" and "data" - and the compiler and link[age]-editor
software technology of the time maintained such.


Whereas 'today', many follow the sequence of "Test-Driven Development"
(er, um, often omitting the initial test) of attempting some idea as
code, reviewing the result, and then "re-factoring" (improving), in a
circular progression - until it not only works, but works well.

This requires similar "stepwise decomposition" to what we learned, but
differs when it comes to code-composition. This approach is more likely
to accumulate a solution 'bottom-up' and component-wise, rather than
creating an entire (and close-to-perfect) solution first and as an whole.


Let's consider the Python REPL. Opening a terminal and starting the
Python interpreter, gives us the opportunity to write short "snippets"
of code and see the results immediately. This is VERY handy for ensuring
that an idea is correct, or to learn exactly how a particular construct
works. Thus, we can 'test' before we write any actual code (and can
copy-paste the successful 'prototype' into our IDE/editor!).

We didn't enjoy such luxury back in the good?bad old days. Young people
today - they just don't know how lucky they are!
(cue other 'grumpy old man' mutterings)


Other points to consider: 'terminals' (cf mainframes), interpreted
languages, and 'immediacy'. These have all brought "opportunities" and
thus "change" to the way developers (can) work and think! (which is why
I outlined what I think of as 'our training' and thus 'our thinking
process' when it comes to software design, above)

Another 'tectonic shift' is that in the old days 'computer time' was
hugely expensive and thus had to be optimised. Whereas these days (even
in retirement) programming-time has become the more expensive component
as computers (or compute-time in cloud-speak) have become cheaper - and
thus we reveal one of THE major attractive attributes of the Python
programming language!


Accordingly, (and now any apologies-due ma

Re: OT: AttributeError

[Greg Ewing]

On 29/09/21 12:21 pm, Chris Angelico wrote:

to the extent that you automatically read 65 and 0x41 as the same
number.


Am I too geeky for reading both of them as 'A'?

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

Re: OT: AttributeError

[Chris Angelico]

On Wed, Sep 29, 2021 at 10:06 AM Greg Ewing  wrote:
>
> On 29/09/21 12:21 pm, Chris Angelico wrote:
> > to the extent that you automatically read 65 and 0x41 as the same
> > number.
>
> Am I too geeky for reading both of them as 'A'?
>

Not even slightly, and I did deliberately choose a printable ASCII
value for that parallel. If E8 03 can be 1000, then 41 68 20 79 65 73
can be "Ah yes".

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

Re: OT: AttributeError

[dn via Python-list]

On 29/09/2021 12.21, Chris Angelico wrote:
> On Wed, Sep 29, 2021 at 9:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>>
>> On 2021-09-29 at 11:38:22 +1300,
>> dn via Python-list  wrote:
>>
>>> For those of us who remember/can compute in binary, octal, hex, or
>>> decimal as-needed:
>>> Why do programmers confuse All Hallows'/Halloween for Christmas Day?
>>
>> That one is also very old.  (Yes, I know the answer.  No, I will not
>> spoil it for those who might not.)  What do I have to do to gain the
>> insight necessary to have discovered that question and answer on my own?
> 
> You'd have to be highly familiar with numbers in different notations,
> to the extent that you automatically read 65 and 0x41 as the same
> number. Or, even better, to be able to read off a hex dump and see E8
> 03 and instantly read it as "1,000 little-endian".

Now, now, young-Chris, make way for those of us who are qualified to
carry walking-sticks!


...or see "C1" and recognise that also to represent an "A"?


To continue, to the bit-ter end:

Sometimes I think you are a bit too much - said the 0 to the 1.

If I hold up two fingers, am I insulting you, or asking for three of
something?

Programming in Java is the process of converting source code into core
dumps.

and, the Dijkstra quotation:
"If debugging is the process of removing bugs, then programming must be
the process of putting them in"

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

Re: OT: AttributeError

[Chris Angelico]

On Wed, Sep 29, 2021 at 11:59 AM dn via Python-list
 wrote:
> If I hold up two fingers, am I insulting you, or asking for three of
> something?
>

A Roman soldier walked into a bar holding up two fingers. "Five beers, please"

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

Re: OT: AttributeError

[2QdxY4RzWzUUiLuE]

On 2021-09-29 at 09:21:34 +1000,
Chris Angelico  wrote:

> On Wed, Sep 29, 2021 at 9:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2021-09-29 at 11:38:22 +1300,
> > dn via Python-list  wrote:
> >
> > > For those of us who remember/can compute in binary, octal, hex, or
> > > decimal as-needed:
> > > Why do programmers confuse All Hallows'/Halloween for Christmas Day?
> >
> > That one is also very old.  (Yes, I know the answer.  No, I will not
> > spoil it for those who might not.)  What do I have to do to gain the
> > insight necessary to have discovered that question and answer on my own?
> 
> You'd have to be highly familiar with numbers in different notations,
> to the extent that you automatically read 65 and 0x41 as the same
> number ...

I do that.  And I have done that, with numbers that size, since the late
1970s (maybe the mid 1970s, for narrow definitions of "different").

There's at least one more [sideways, twisted] leap to the point that you
even think of translating the names of those holidays into an arithmetic
riddle.

> ... Or, even better, to be able to read off a hex dump and see E8 03
> and instantly read it as "1,000 little-endian".

59535 big endian.  Warningm flamebait ahead:  Who thinks in little
endian?  (I was raised on 6502s and 680XX CPUs; 8080s and Z80s always
did things backwards.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: AttributeError

[2QdxY4RzWzUUiLuE]

On 2021-09-29 at 09:21:34 +1000,
Chris Angelico  wrote:

> ... read off a hex dump and see E8
> 03 and instantly read it as "1,000 little-endian".

ITYM 000,1 little-endian.  ;-)

(Or possibly 000.1, depending on your locale.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: AttributeError

[Chris Angelico]

On Wed, Sep 29, 2021 at 12:06 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > ... Or, even better, to be able to read off a hex dump and see E8 03
> > and instantly read it as "1,000 little-endian".
>
> 59535 big endian.  Warningm flamebait ahead:  Who thinks in little
> endian?  (I was raised on 6502s and 680XX CPUs; 8080s and Z80s always
> did things backwards.)

I do, because most of the file formats I've had to delve into have
been little-endian. It seems to be far more common to have
undocumented file formats created by Windows programs than, say,
undocumented network packet formats (which would use network byte
order, naturally).

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

FlaskCon's CFP is now open till Oct 24

[Abdur-Rahmaan Janhangeer]

Greetings folks,

FlaskCon is around again this year, the very latest conf of the year.
Bouncing in the first week of December, 1 2 3 4.

CFP is open, submit -> https://flaskcon.com/

Any queries, let them fly to flask...@gmail.com

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

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