How to write list of integers to file with struct.pack_into?

2023-10-03 Thread Jen Kris via Python-list
My previous message just went up -- sorry for the mangled formatting.  Here it 
is properly formatted:

I want to write a list of 64-bit integers to a binary file.  Every example I 
have seen in my research converts it to .txt, but I want it in binary.  I wrote 
this code, based on some earlier work I have done:

    buf = bytes((len(qs_array)) * 8)
    for offset in range(len(qs_array)):
    item_to_write = bytes(qs_array[offset])
    struct.pack_into(buf, "https://mail.python.org/mailman/listinfo/python-list


Re: How to write list of integers to file with struct.pack_into?

2023-10-03 Thread Roel Schroeven via Python-list



Jen Kris via Python-list schreef op 2/10/2023 om 17:06:

My previous message just went up -- sorry for the mangled formatting.  Here it 
is properly formatted:

I want to write a list of 64-bit integers to a binary file.  Every example I 
have seen in my research converts it to .txt, but I want it in binary.  I wrote 
this code, based on some earlier work I have done:

     buf = bytes((len(qs_array)) * 8)
     for offset in range(len(qs_array)):
     item_to_write = bytes(qs_array[offset])
     struct.pack_into(buf, "

Shouldn't the two first parameters be swapped, like this?

    struct.pack_into("Also it wouldn't surprise me if you had to use offset*8 instead of just 
offset in that pack_into() call -- I would think the offset is specified 
in bytes.


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams
--
https://mail.python.org/mailman/listinfo/python-list


Re: type annotation vs working code

2023-10-03 Thread dn via Python-list

On 02/10/2023 00.57, Karsten Hilbert via Python-list wrote:

Sorry for having conflated the core of the matter with all
the Borg shenanigans, that's where I found the problem in my
real code, so there :-)


The first question when dealing with the Singleton Pattern is what to do 
when more than one instantiation is attempted:


- silently return the first instance
- raise an exception


The 'problem' interpreting the original code was that the 'Borg 
Pattern', is not limited in number, but is where some class-attribute 
list (or dict) is used to enable all instances to be aware of each of 
the others (IIRC).


Is choosing names as important as selecting/implementing smart algorithms?



Consider this:

#
class Surprise:
def __init__(self, with_type_annotation=False):
if with_type_annotation:
try:
self.does_not_exist:bool
print('does_not_exist does exist')
except AttributeError:
print('does_not_exist does not exist')
return

try:
self.does_not_exist
print('does_not_exist does exist')
except AttributeError:
print('does_not_exist does not exist')

Surprise(with_type_annotation = False)
Surprise(with_type_annotation = True)
#

Is this how it is supposed to be ?


Wasn't this answered earlier? (@Mats)

That self.does_not_exist:bool isn't interpreted by Python to mean the 
same as self.does_not_exist.




...and so we're addressing the important question: the try-test is for 
existence, cf for
some value.

This can also be achieved by using the attribute in a legal expression, eg:

...

Might this remove the confusion (ref: @Mats):

 self.already_initialized:bool == True


Not for me as that would _create_ already_initialized on the
instance. It would not allow me to test for it.


Which seems akin constructs for generating compatibility
between versions.


versions of ?


Of the language. Sometimes one tests for existence of a given
class in a module and defines said class oneself if it does
not exist. But that's leading astray.


What is the intent: a class where each instance is aware of every other 
instance - yet
the word "Singleton" implies there's only one (cf a dict full of ...)?


The latter.


and so, returning to the matter of 'readability':

- the name "Borg" de-railed comprehension

- _instances:dict = {} implied the tracking of more than one

- should the class have been called either;

class SomethingSingleton():

or a Singleton() class defined, which is then sub-classed, ie

class Something( Singleton ):

in order to better communicate the coder's intent to the reader?

- from there, plenty of 'templates' exist for Singletons, so why do 
something quite different/alien to the reader?

(thus concurring with @Richard: "tricky" subverts 'readability')

- is it better to use a technique which 'we' will recognise, or to ask 
'us' to comprehend something 'new'?
(unless the 'new' is taking-advantage of a recent extension to the 
language, eg switch; to justify 'trail-blazing' a 
new/improved/replacement 'best practice')


- part of the 'tricky' seems to be an attempt to assess using an 
instance-attribute, rather than a class-attribute. If the :bool (or 
whichever) typing-annotation is added to a class-attribute (eg 
_instance), will the problem arise?


- does the sequence

_instance = False
...
if not cls._instance:
ie the explicit version
if cls._instance == False:

measure 'existence' or a value?

- does the sequence

_instance = None
...
if not cls._instance:
ie the explicit version:
if cls._instance is None:

measure 'existence' or identity?
(indeed, are they more-or-less the same concept?)

- do the *attr() functions test for 'existence'?

(that said, most of the code-examples I spotted, in reading-up on this, 
use either None or False - et tu Brute!)



Speaking of reading-up:

- am wondering where PEP 661 - Sentinel Values is 'going'?

- this article (https://python-patterns.guide/gang-of-four/singleton/) 
mentions that the original GoF Singleton Pattern preceded Python 
(particularly Python 3 classes). Also, that Python doesn't have 
complications present in C++. It further discusses "several drawbacks", 
which also champion 'readability' over 'trick' or 'sophistication'. I 
think you'll enjoy it!


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


Re: type annotation vs working code

2023-10-03 Thread Chris Angelico via Python-list
On Wed, 4 Oct 2023 at 15:27, dn via Python-list  wrote:
> - should the class have been called either;
>
>  class SomethingSingleton():
>
> or a Singleton() class defined, which is then sub-classed, ie
>
>  class Something( Singleton ):
>
> in order to better communicate the coder's intent to the reader?

TBH, I don't think it's right to have a Singleton class which is
subclassed by a bunch of different singletons. They aren't really
subclasses of the same class. I could imagine Singleton being a
metaclass, perhaps, but otherwise, they're not really similar to each
other.

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


Re: type annotation vs working code

2023-10-03 Thread Greg Ewing via Python-list

On 4/10/23 5:25 pm, dn wrote:
The first question when dealing with the Singleton Pattern is what to do 
when more than one instantiation is attempted


My preferred way of handling singletons is not to expose the class
itself, but a function that creates an instance the first time it's
called, and returns that instance subsequently. The problem then
doesn't arise.

--
Greg

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


Re: type annotation vs working code

2023-10-03 Thread Chris Angelico via Python-list
On Wed, 4 Oct 2023 at 17:47, Greg Ewing via Python-list
 wrote:
>
> On 4/10/23 5:25 pm, dn wrote:
> > The first question when dealing with the Singleton Pattern is what to do
> > when more than one instantiation is attempted
>
> My preferred way of handling singletons is not to expose the class
> itself, but a function that creates an instance the first time it's
> called, and returns that instance subsequently. The problem then
> doesn't arise.
>

That's one option. Personally, I don't use them very much, but if I
do, it's usually actually as a class that never gets instantiated:

class PileOfAttributes:
x = 1
y = 2
spam = "ham"

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