Re: Python-pickle error
Charles,
by your own admission, you deleted your pkl file,
And your code doesn't write that pkl file (pickle.dumps(...) doesn't
write a file it creates a new string and at no point will it write to
the file :
What you need is this :
import pickle
number=2
my_pickled_object=pickle.dumps(number)
with open('file.pkl', 'w') as file:
file.write(my_pickled_object)
print("this is my pickled object",{my_pickled_object},)
del number # you can do this if you really want to test pickle.
with open('file.pkl', 'r') as file:
number=pickle.load(file)
my_unpickled_object=pickle.loads(my_pickled_object)
print("this is my unpickled object",{my_unpickled_object},)
Note : that the whole point of the pickle format is that you don't need
to open and write/read files in binary format.
On 19/04/2023 17:14, charles wiewiora wrote:
Hello,
I am experincing problems with the pickle moducle
the folowing code was working before,
import pickle
number=2
my_pickeld_object=pickle.dumps(number)
print("this is my pickled object",{my_pickeld_object},)
with open('file.pkl', 'rb') as file:
number=pickle.load(file)
my_unpickeled_object=pickle.loads(my_pickeld_object)
print("this is my unpickeled object",{my_unpickeled_object},)
but now i get error
Traceback (most recent call last):
File "C:\Users\lukwi\Desktop\python\tester2.py", line 5, in
with open('file.pkl', 'rb') as file:
FileNotFoundError: [Errno 2] No such file or directory: 'file.pkl'
im get this problem after this,
a .pkl came into my Python script files
i though this could be a spare file made from python becauce i was doing this
first,
import pickle
number=2
my_pickeld_object=pickle.dumps(number)
print("this is my pickled object",{my_pickeld_object},)
with open('file.pkl', 'rb') as file:
number=pickle.load(file)
so i stupidly deleted the file
do you know how to fix this?
i reinstalled it but it didn't work
this is on widnows and on version 3.11.3 on python
thank you
--
Anthony Flury
email : anthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyinstaller wrong classified as Windows virus
Have you tried using Nuitka - rather than pyInstalller - it means you distribute a single executable and the Python run time library (which they probably have already), and it has the advantage that it is a bit quicker than standard python. Rather than bundle the source code and interpreter in single executable, Nuitka actually compiles the Python source code to native machine code (via a set of C files), and this native executable uses the Python runtime library to implement the python features.It does rely on you having a Windows C compiler available. On 25/11/2021 17:10, Ulli Horlacher wrote: Chris Angelico wrote: Unfortunately, if you're not going to go to the effort of getting your executables signed I cannot sign my executables (how can I do it anyway?), because Windows deletes my executable as soon as I have compiled them! They exist only for a few seconds and then they are gone. another reason to just distribute .py files. I cannot do that because my users do not have Python installed and they are not allowed to do it. -- https://mail.python.org/mailman/listinfo/python-list
Puzzling behaviour of Py_IncRef
I am writing a C extension module for an AVL tree, and I am trying to
ensure reference counting is done correctly. I was having a problem with
the reference counting so I worked up this little POC of the problem,
and I hope someone can explain this.
Extension function :
static PyObject *_Node_test_ref_count(PyObject *self)
{
printf("\nIncrementing ref count for self - just for the hell
of it\n");
printf("\n before self has a ref count of %ld\n", Py_REFCNT(self));
Py_INCREF(self);
printf("\n after self has a ref count of %ld\n", Py_REFCNT(self));
fflush(stdout);
return self;
}
As you can see this function purely increments the reference count of
the instance.
/Note: I understand normally this would be the wrong this to do, but
this is a POC of the issue, not live code. In the live code I am
attaching a 2nd nodes to each other, and the live code therefore
increments the ref-count for both objects - so even if the Python code
deletes it's reference the reference count for the instance should still
be 1 in order to ensure it doesn't get garbage collected./
This function is exposed as the test_ref method.
This is the test case :
def test_000_009_test_ref_count(self):
node = _Node("Hello")
self.assertEqual(sys.getrefcount(node), 2)
node.test_ref()
self.assertEqual(sys.getrefcount(node), 3)
The output of this test case is :
test_000_009_test_ref_count (__main__.TestNode) ...
Incrementing ref count for self - just for the hell of it
before self has a ref count of 2
after self has a ref count of 3
FAIL
==
FAIL: test_000_009_test_ref_count (__main__.TestNode)
--
Traceback (most recent call last):
File
"/home/tony/Development/python/orderedtree/tests/test_orderedtree.py",
line 62, in test_000_009_test_ref_count
self.assertEqual(sys.getrefcount(node), 3)
AssertionError: 2 != 3
So I understand why the first assert will be true - when the
sys.getrefcount() function is called the ref count is incremented
temporarily (as a borrowed reference), so there are now two references -
the 'node' variable, and the borrowed reference in the function call.
We then call the 'test_ref' method, and again that call causes a
borrowed reference (hence the ref count being 2 initially within the
method). The 'test_ref' method increments the reference of the instance
- as you can see from the output we now have a ref count of 3 - (that
count is the 'node' variable in the test case, the borrowed reference
due to the method call, and the artificial increment from the 'ref_test'
method).
When the 'ref_test' method exits I would expect the ref count of the
instance to now be 2 (one for the 'node' variable, and one as a result
of the artificial increment increment').
I would therefore expect the 2nd assertEqual in the test case to
succeed. - in this case the borrowed reference within sys.getfrefcount()
should cause the count to be 3.
As you see though that 2nd assertEqual fails - suggesting that the
refcount of 'node' is actually only 1 when the 'test_ref' method exits.
Can someone explain why the 'test_ref' method fails to change the
refcount of the 'node' instance.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Puzzling behaviour of Py_IncRef
On 19/01/2022 11:09, Chris Angelico wrote:
On Wed, Jan 19, 2022 at 10:00 PM Tony Flury via Python-list
wrote:
Extension function :
static PyObject *_Node_test_ref_count(PyObject *self)
{
printf("\nIncrementing ref count for self - just for the hell
of it\n");
printf("\n before self has a ref count of %ld\n", Py_REFCNT(self));
Py_INCREF(self);
printf("\n after self has a ref count of %ld\n", Py_REFCNT(self));
fflush(stdout);
At this point, the refcount has indeed been increased.
return self;
}
And then you say "my return value is this object".
The normal thing to do is to add a reference to whatever you're
returning. For instance, Py_RETURN_NONE will incref None and then
return it.
So you're incrementing the refcount, then returning it without
incrementing the refcount. Your code is actually equivalent to "return
self".
In order to actually leak a reference, you'd need to incref it twice.
ChrisA
Chris - I am still puzzled - does doing 'return self' automatically
decrement the ref count of the object ?, and why is that the desired
behaviour ? Effectively it results in a decrement of two, since at the
exit of the function the ref count is only 1 (as witnessed by the
subsequent call to assertEqual).
(I am not suggesting that it should be changed - I understand that would
be a breaking change !).
You say I am returning it without incrementing, but I am explicitly
incrementing it before the return.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Puzzling behaviour of Py_IncRef
On 20/01/2022 23:12, Chris Angelico wrote: On Fri, 21 Jan 2022 at 10:10, Greg Ewing wrote: On 20/01/22 12:09 am, Chris Angelico wrote: At this point, the refcount has indeed been increased. return self; } And then you say "my return value is this object". So you're incrementing the refcount, then returning it without incrementing the refcount. Your code is actually equivalent to "return self". Chris, you're not making any sense. This is C code, so there's no way that "return x" can change the reference count of x. Yeah, I wasn't clear there. It was equivalent to *the Python code* "return self". My apologies. > The normal thing to do is to add a reference to whatever you're > returning. For instance, Py_RETURN_NONE will incref None and then > return it. > The OP understands that this is not a normal thing to do. He's trying to deliberately leak a reference for the purpose of diagnosing a problem. It would be interesting to see what the actual refcount is after calling this function. After calling this without a double increment in the function the ref count is still only 1 - which means that the 'return self' effectively does a double decrement. My original message includes the Python code which calls this 'leaky' function and you can see that despite the 'leaky POC' doing an increment ref count drops back to one after the return. You are right this is not a normal thing to do, I am trying to understand the behaviour so my library does the correct thing in all cases - for example - imagine you have two nodes in a tree : A --- > B And your Python code has a named reference to A, and B also maintains a reference to A as it's parent. In this case I would expect A to have a reference count of 2 (counted as 3 through sys.getrefcount() - one for the named reference in the Python code - and one for the link from B back to A; I would also expect B to have a reference count here of 1 (just the reference from A - assuming nothing else referenced B). My original code was incrementing the ref counts of A and B and then returning A. within the Python test code A had a refcount of 1 (and not the expected 2), but the refcount from B was correct as far as I could tell. Yes, and that's why I was saying it would need a *second* incref. ChrisA Thank you to all of you for trying to help - I accept that the only way to make the code work is to do a 2nd increment. I don't understand why doing a 'return self' would result in a double decrement - that seems utterly bizzare behaviour - it obviously works, but why. -- Anthony Flury email : anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Puzzling behaviour of Py_IncRef
On 25/01/2022 22:28, Barry wrote: On 25 Jan 2022, at 14:50, Tony Flury via Python-list wrote: On 20/01/2022 23:12, Chris Angelico wrote: On Fri, 21 Jan 2022 at 10:10, Greg Ewing wrote: On 20/01/22 12:09 am, Chris Angelico wrote: At this point, the refcount has indeed been increased. return self; } And then you say "my return value is this object". So you're incrementing the refcount, then returning it without incrementing the refcount. Your code is actually equivalent to "return self". Chris, you're not making any sense. This is C code, so there's no way that "return x" can change the reference count of x. Yeah, I wasn't clear there. It was equivalent to *the Python code* "return self". My apologies. > The normal thing to do is to add a reference to whatever you're > returning. For instance, Py_RETURN_NONE will incref None and then > return it. > The OP understands that this is not a normal thing to do. He's trying to deliberately leak a reference for the purpose of diagnosing a problem. It would be interesting to see what the actual refcount is after calling this function. After calling this without a double increment in the function the ref count is still only 1 - which means that the 'return self' effectively does a double decrement. My original message includes the Python code which calls this 'leaky' function and you can see that despite the 'leaky POC' doing an increment ref count drops back to one after the return. You are right this is not a normal thing to do, I am trying to understand the behaviour so my library does the correct thing in all cases - for example - imagine you have two nodes in a tree : A --- > B And your Python code has a named reference to A, and B also maintains a reference to A as it's parent. In this case I would expect A to have a reference count of 2 (counted as 3 through sys.getrefcount() - one for the named reference in the Python code - and one for the link from B back to A; I would also expect B to have a reference count here of 1 (just the reference from A - assuming nothing else referenced B). My original code was incrementing the ref counts of A and B and then returning A. within the Python test code A had a refcount of 1 (and not the expected 2), but the refcount from B was correct as far as I could tell. Yes, and that's why I was saying it would need a *second* incref. ChrisA Thank you to all of you for trying to help - I accept that the only way to make the code work is to do a 2nd increment. I don't understand why doing a 'return self' would result in a double decrement - that seems utterly bizzare behaviour - it obviously works, but why. The return self in C will not change the ref count. I would suggest setting a break point in your code and stepping out of the function and seeing that python’s code does to the ref count. Barry Barry, something odd is going on because the Python code isn't doing anything that would cause the reference count to go from 3 inside the C function to 1 once the method call is complete. As far as I know the only things that impact the reference counts are : * Increments due to assigning a new name or adding it to a container. * Increment due to passing the object to a function (since that binds a new name) * Decrements due to deletion of a name * Decrement due to going out of scope * Decrement due to being removed from a container. None of those things are happening in the python code. As posted in the original message - immediately before the call to the C function/method sys.getrefcount reports the count to be 2 (meaning it is actually a 1). Inside the C function the ref count is incremented and the Py_REFCNT macro reports the count as 3 inside the C function as expected (1 for the name in the Python code, 1 for the argument as passed to the C function, and 1 for the increment), so outside the function one would expect the ref count to now be 2 (since the reference caused by calling the function is then reversed). However - Immediately outside the C function and back in the Python code sys.getrefcount reports the count to be 2 again - meaning it is now really 1. So that means that the refcount has been decremented twice in-between the return of the C function and the execution of the immediate next python statement. I understand one of those decrements - the parameter's ref count is incremented on the way in so the same object is decremented on the way out (so that calls don't leak references) but I don't understand where the second decrement is coming from. Again there is nothing in the Python code that would cause that decrement - the decrement behavior is in the Python runtime. -- Anthony Flury email :anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list -- Anthony Flury email :anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Puzzling behaviour of Py_IncRef
On 26/01/2022 01:29, MRAB wrote: On 2022-01-25 23:50, Tony Flury via Python-list wrote: On 25/01/2022 22:28, Barry wrote: On 25 Jan 2022, at 14:50, Tony Flury via Python-list wrote: On 20/01/2022 23:12, Chris Angelico wrote: On Fri, 21 Jan 2022 at 10:10, Greg Ewing wrote: On 20/01/22 12:09 am, Chris Angelico wrote: At this point, the refcount has indeed been increased. return self; } And then you say "my return value is this object". So you're incrementing the refcount, then returning it without incrementing the refcount. Your code is actually equivalent to "return self". Chris, you're not making any sense. This is C code, so there's no way that "return x" can change the reference count of x. Yeah, I wasn't clear there. It was equivalent to *the Python code* "return self". My apologies. > The normal thing to do is to add a reference to whatever you're > returning. For instance, Py_RETURN_NONE will incref None and then > return it. > The OP understands that this is not a normal thing to do. He's trying to deliberately leak a reference for the purpose of diagnosing a problem. It would be interesting to see what the actual refcount is after calling this function. After calling this without a double increment in the function the ref count is still only 1 - which means that the 'return self' effectively does a double decrement. My original message includes the Python code which calls this 'leaky' function and you can see that despite the 'leaky POC' doing an increment ref count drops back to one after the return. You are right this is not a normal thing to do, I am trying to understand the behaviour so my library does the correct thing in all cases - for example - imagine you have two nodes in a tree : A --- > B And your Python code has a named reference to A, and B also maintains a reference to A as it's parent. In this case I would expect A to have a reference count of 2 (counted as 3 through sys.getrefcount() - one for the named reference in the Python code - and one for the link from B back to A; I would also expect B to have a reference count here of 1 (just the reference from A - assuming nothing else referenced B). My original code was incrementing the ref counts of A and B and then returning A. within the Python test code A had a refcount of 1 (and not the expected 2), but the refcount from B was correct as far as I could tell. Yes, and that's why I was saying it would need a *second* incref. ChrisA Thank you to all of you for trying to help - I accept that the only way to make the code work is to do a 2nd increment. I don't understand why doing a 'return self' would result in a double decrement - that seems utterly bizzare behaviour - it obviously works, but why. The return self in C will not change the ref count. I would suggest setting a break point in your code and stepping out of the function and seeing that python’s code does to the ref count. Barry Barry, something odd is going on because the Python code isn't doing anything that would cause the reference count to go from 3 inside the C function to 1 once the method call is complete. As far as I know the only things that impact the reference counts are : * Increments due to assigning a new name or adding it to a container. * Increment due to passing the object to a function (since that binds a new name) * Decrements due to deletion of a name * Decrement due to going out of scope * Decrement due to being removed from a container. None of those things are happening in the python code. As posted in the original message - immediately before the call to the C function/method sys.getrefcount reports the count to be 2 (meaning it is actually a 1). Inside the C function the ref count is incremented and the Py_REFCNT macro reports the count as 3 inside the C function as expected (1 for the name in the Python code, 1 for the argument as passed to the C function, and 1 for the increment), so outside the function one would expect the ref count to now be 2 (since the reference caused by calling the function is then reversed). However - Immediately outside the C function and back in the Python code sys.getrefcount reports the count to be 2 again - meaning it is now really 1. So that means that the refcount has been decremented twice in-between the return of the C function and the execution of the immediate next python statement. I understand one of those decrements - the parameter's ref count is incremented on the way in so the same object is decremented on the way out (so that calls don't leak references) but I don't understand where the second decrement is coming from. Again there is nothing in the Python code that would cause that decrement - the decrement behavior is i
Re: Puzzling behaviour of Py_IncRef
On 26/01/2022 08:20, Chris Angelico wrote: On Wed, 26 Jan 2022 at 19:04, Tony Flury via Python-list wrote: So according to that I should increment twice if and only if the calling code is using the result - which you can't tell in the C code - which is very odd behaviour. No, the return value from your C function will *always* have a reference taken. Whether the return value is "used" or just dropped, there's always going to be one ref used by the returning itself. The standard way to return a value is always to incref it, then return the pointer. That is exactly equivalent to Python saying "return ". Incrementing twice is ONLY because you want to leak a reference. ChrisA Chris, You keep saying I am leaking a reference - my original code (not the POC in the email) wasn't intending to leak a reference, it was incrementing the reference count in order to accurately count references, from other objects and i needed to double increment there so that the reference count remained correct outside of the C code. I did try to be clear - my intention was never to leak a reference (I have been writing s/w long enough to know leaks are bad) - my POC code in the original message was the only code which deliberately leaked a reference in order to simply illustrate the problem. I do appreciate the help you have tried to give - so thank you. -- Anthony Flury email : anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Puzzling behaviour of Py_IncRef
On 26/01/2022 22:41, Barry wrote: Run python and your code under a debugger and check the ref count of the object as you step through the code. Don’t just step through your code but also step through the C python code. That will allow you to see how this works at a low level. Setting a watch point on the ref count will allow you run the code and just break as the ref count changes. That is what I do when a see odd c api behaviour. Barry Thanks - I have tried a few times on a few projects to run a debugger in mixed language mode and never had any success. I will have to try again. As posted in the original message - immediately before the call to the C function/method sys.getrefcount reports the count to be 2 (meaning it is actually a 1). Inside the C function the ref count is incremented and the Py_REFCNT macro reports the count as 3 inside the C function as expected (1 for the name in the Python code, 1 for the argument as passed to the C function, and 1 for the increment), so outside the function one would expect the ref count to now be 2 (since the reference caused by calling the function is then reversed). However - Immediately outside the C function and back in the Python code sys.getrefcount reports the count to be 2 again - meaning it is now really 1. So that means that the refcount has been decremented twice in-between the return of the C function and the execution of the immediate next python statement. I understand one of those decrements - the parameter's ref count is incremented on the way in so the same object is decremented on the way out (so that calls don't leak references) but I don't understand where the second decrement is coming from. Again there is nothing in the Python code that would cause that decrement - the decrement behavior is in the Python runtime. -- Anthony Flury email :anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list -- Anthony Flury email :anthony.fl...@btinternet.com -- Anthony Flury email : anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Starting using Python
On 03/01/2022 12:45, Joao Marques wrote: Good morning: I have a very simple question: I want to start writing programs in Python so I went to the Microsoft Store and installed Python3.9. No problem so far. I would prefer to have a gui interface, an interface that I can use file-->Open and File-->Save as, as I see it on different videos. How can I get it? Because my problem is to run the programs I have already written and saved on a *.py file in my own working directory, not in the Python's CWD directory. Can you please help? I am running Windows 10 Pro version 20H2 Regards, Joao The simplest Python GUI editor is IDLE, which should come installed with with Python. On windows just open the start menu and type 'IDLE' You can save your python files anywhere - you shouldn't need to save it in Python's working directory. Python doesn't impose any particular file system until you start implement features such as packages which are not something a beginner should ever worry about. -- Anthony Flury email : anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list
Re: on sorting things
On 20/12/2019 18:59, Peter Otten wrote: Chris Angelico wrote: On Sat, Dec 21, 2019 at 5:03 AM Peter Otten <__pete...@web.de> wrote: PS: If you are sorting files by size and checksum as part of a deduplication effort consider using dict-s instead: Yeah, I'd agree if that's the purpose. But let's say the point is to have a guaranteed-stable ordering of files that are primarily to be sorted by file size - in order to ensure that two files are in the same order every time you refresh the view, they get sorted by their checksums. One thing that struck me about Eli's example is that it features two key functions rather than a complex comparison. If sort() would accept a sequence of key functions each function could be used to sort slices that compare equal when using the previous key. You don't need a sequence of key functions : the sort algorithm used in Python (tim-sort) is stable - which means if two items (A &B) are in a given order in the sequence before the sort starts, and A & B compare equal during the sort, then after the sort A & B retain their ordering. So if you want to sort by file size as the primary and then by checksum if file sizes are equal - you sort by checksum first, and then by file size: this guarantees that the items will always be in file size order - and if file sizes are equal then they will be ordered by checksum. The rule to remember - is sort in the reverse order of criteria. There ARE good reasons to do weird things with sorting, and a custom key object (either with cmp_to_key or directly implemented) can do that. Indeed. -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: For Loop Invariants
On 10/04/2020 21:44, Elliott Dehnbostel wrote:
*We could do this:*
chars = "abcaaabkjzhbjacvb"
seek = {'a','b','c'}
count = sum([1 for a in chars if a in seek])
However, this changes important semantics by creating an entire new
list before summing.
Creating the list is pointless in this case - sum will take any
iterable, including a generator expression:
chars = "abcaaabkjzhbjacvb"
seek = {'a','b','c'}
count = sum(1 for a in chars if a in seek)
So you haven't really changed any semantics - and it seems that this is
far better than fiddling with the for loop syntax.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Function to avoid a global variable
On 28/04/2020 06:49, jf...@ms4.hinet.net wrote: bvdp於 2020年4月28日星期二 UTC+8上午9時46分35秒寫道： Oh my, that is very cool! So, I can do this: def foo(i): if not 'bar' in foo.__dict__: foo.bar = 5 foo.bar += i You can have function attribute created this way if you like: def foo(i): foo.bar += i foo.bar = 5 --Jach And as you have shown - foo.bar is effectively a global variable - just one with a qualified name :-) -- Tony Flury -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On 24/04/2020 19:40, Manfred Lotz wrote:
I have a command like application which checks a directory tree for
certain things. If there are errors then messages will be written to
stdout.
How to test this in the best way?
One idea was for the error situations to write messages to files and
then later when running the tests to compare the error messages output
to the previously saved output.
Is there anything better?
In a recent application that I wrote (where output to the console was
important), I tested it using the 'unittest' framework, and by patching
sys.stderr to be a StringIO - that way my test case could inspect what
was being output.
with patch('sys.stderr', StringIO()) as
stderr:application.do_stuff()self.assertTrue(stderr.getvalue(),
'Woops - that didn\'t work')
I am not sure of the structure of your application, and whether you have a
callable API that you can invoke.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Floating point problem
On 18/04/2020 15:29, Grant Edwards wrote: On 2020-04-18, Souvik Dutta wrote: I literally tried it!!! And it did not stop because I did not get any 1.0 rather I got 0.999 But why does this happen. This is a simple math which according to normal human logic should give perfect numbers which are not endless. Then why does a computer behave so differently? Because computers _don't_do_math_. That is a very important thing to remember. Computer do something that _approximates_ math... in some situations... if you know what you're doing. In you're case you're doing IEEE floating point operations. Before you use floating point, you should read the article by Goldman that has been suggested: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html https://dl.acm.org/doi/10.1145/103162.103163 There is also https://docs.python.org/3/tutorial/floatingpoint.html In the official Python documentation, well worth reading. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Solved: Re: Missing python curses functions?
Maybe you should raise a bug (bugs.python.org) and flag that this
function is missing.
It could be that it can be introduced by whoever is maintaining the
existing code.
On 20/05/2020 08:31, Alan Gauld via Python-list wrote:
On 19/05/2020 20:53, Alan Gauld via Python-list wrote:
One of the functions discussed that does not appear to have
a Python equivalent is attr_get() which gets the current
attributes.
OK, Using inch() I've written the following function:
def attr_get(win):
""" return current window attributes.
If a character exists at the bottom right position it will be lost!
"""
y,x = win.getmaxyx() # how many lines in the window?
win.insch(y-1,0,' ') # insert a space at bottom left
ch = win.inch(y-1,0) # now read the char (including attributes)
win.delch(y-1,0) # remove the char from window
return ch
And it can be used like:
import curses
scr = curses.initscr()
# uncomment next line to test
# scr.attrset(curses.A_UNDERLINE)
atts = attr_get(scr)
if atts & cur.A_UNDERLINE:
scr.addstr("Underline is on")
else:
scr.addstr("Underline is off")
scr.refresh()
scr.getch()
curses.endwin()
Just in case its useful to anyone else...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Any ideas for a new language inspired to Python?
On 08/08/2020 18:18, Marco Sulla wrote: Thank you, some features are interesting, even if I prefer the Python syntax. What about the compiler? Is it better to "compile" to C or to bytecode? How can I generate a bytecode that can be compiled by gcc? Can I skip the AST generation for now, or it will be a great problem later? Most modern compilers use an AST - it is simply an internal representation of the syntax, and for most compilers it it is an intermediate step before code generation. I think you mean skipping the bytecode generation and generating straight to C/machine code. -- Tony Flury -- https://mail.python.org/mailman/listinfo/python-list
Simple question - end a raw string with a single backslash ?
I am trying to write a simple expression to build a raw string that ends in a single backslash. My understanding is that a raw string should ignore attempts at escaping characters but I get this : >>> a = r'end\' File "", line 1 a = r'end\' ^ SyntaxError: EOL while scanning string literal I interpret this as meaning that the \' is actually being interpreted as a literal quote - is that a bug ? If I try to escaped the backslash I get a different problem: >>> a = r'end\\' >>> a 'end' >>> print(a) end\\ >>> len(a) 5 >>> list(a) ['e', 'n', 'd', '\\', '\\'] So you can see that our string (with the escaped backslash) is now 5 characters with two literal backslash characters The only solution I have found is to do this : >>> a = r'end' + chr(92) >>> a 'end\\' >>> list(a) ['e', 'n', 'd', '\\'] or >>> a = r'end\\'[:-1] >>> list(a) ['e', 'n', 'd', '\\'] Neither of which are nice. -- https://mail.python.org/mailman/listinfo/python-list
Re: Embedding version in command-line program
On 07/10/2020 12:06, Loris Bennett wrote: Hi, I have written a program, which I can run on the command-line thus mypyprog --version and the get the version, which is currently derived from a variable in the main module file. However, I also have the version in an __init__.py file and in a pyproject.toml (as I'm using poetry, otherwise this would be in setup.py). What's the best way of reducing these three places where the version is defined to a single one? Cheers, Loris My top level package always has a version.py file which defines __version__, __author__ etc. I am not sure if that helps in your .toml file though - is it executed or does it have the ability to read files when it creates the distributable ? -- https://mail.python.org/mailman/listinfo/python-list
Is there a way to implement the ** operator on a custom object
I know that mappings by default support the ** operator, to unpack the mapping into key word arguments. Has it been considered implementing a dunder method for the ** operator so you could unpack an object into a key word argument, and the developer could choose which keywords would be generated (or could even generate 'virtual' attributes). -- Anthony Flury email : anthony.fl...@btinternet.com -- https://mail.python.org/mailman/listinfo/python-list
