Re: Is there a more efficient threading lock?
On Mon, 27 Feb 2023 at 17:28, Michael Speer wrote: > > https://github.com/python/cpython/commit/4958f5d69dd2bf86866c43491caf72f774ddec97 > > it's a quirk of implementation. the scheduler currently only checks if it > needs to release the gil after the POP_JUMP_IF_FALSE, POP_JUMP_IF_TRUE, > JUMP_ABSOLUTE, CALL_METHOD, CALL_FUNCTION, CALL_FUNCTION_KW, and > CALL_FUNCTION_EX opcodes. > Oh now that is VERY interesting. It's a quirk of implementation, yes, but there's a reason for it; a bug being solved. The underlying guarantee about __exit__ should be considered to be defined behaviour, meaning that the precise quirk might not be relevant even though the bug has to remain fixed in all future versions. But I'd also note here that, if it can be absolutely 100% guaranteed that the GIL will be released and signals checked on a reasonable interval, there's no particular reason to state that signals are checked after every single Python bytecode. (See the removed comment about empty loops, which would have been a serious issue and is probably why the backward jump rule exists.) So it wouldn't be too hard for a future release of Python to mandate atomicity of certain specific operations. Obviously it'd require buy-in from other implementations, but it would be rather convenient if, subject to some very tight rules like "only when adding integers onto core data types" etc, a simple statement like "x.y += 1" could actually be guaranteed to take place atomically. Though it's still probably not as useful as you might hope. In C, if I can do "int id = counter++;" atomically, it would guarantee me a new ID that no other thread could ever have. But in Python, that increment operation doesn't give you the result, so all it's really useful for is statistics on operations done. Still, that in itself could be of value in quite a few situations. In any case, though, this isn't something to depend upon at the moment. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
https://stackoverflow.com/questions/69993959/python-threads-difference-for-3-10-and-others https://github.com/python/cpython/commit/4958f5d69dd2bf86866c43491caf72f774ddec97 it's a quirk of implementation. the scheduler currently only checks if it needs to release the gil after the POP_JUMP_IF_FALSE, POP_JUMP_IF_TRUE, JUMP_ABSOLUTE, CALL_METHOD, CALL_FUNCTION, CALL_FUNCTION_KW, and CALL_FUNCTION_EX opcodes. >>> import code >>> import dis >>> dis.dis( code.update_x_times ) 10 0 LOAD_GLOBAL 0 (range) 2 LOAD_FAST0 (xx) 4 CALL_FUNCTION1 # GIL CAN RELEASE HERE # 6 GET_ITER >>8 FOR_ITER 6 (to 22) 10 STORE_FAST 1 (_) 12 12 LOAD_GLOBAL 1 (vv) 14 LOAD_CONST 1 (1) 16 INPLACE_ADD 18 STORE_GLOBAL 1 (vv) 20 JUMP_ABSOLUTE4 (to 8) # GIL CAN RELEASE HERE (after JUMP_ABSOLUTE points the instruction counter back to FOR_ITER, but before the interpreter actually jumps to FOR_ITER again) # 10 >> 22 LOAD_CONST 0 (None) 24 RETURN_VALUE >>> due to this, this section: 12 12 LOAD_GLOBAL 1 (vv) 14 LOAD_CONST 1 (1) 16 INPLACE_ADD 18 STORE_GLOBAL 1 (vv) is effectively locked/atomic on post-3.10 interpreters, though this is neither portable nor guaranteed to stay that way into the future On Sun, Feb 26, 2023 at 10:19 PM Michael Speer wrote: > I wanted to provide an example that your claimed atomicity is simply > wrong, but I found there is something different in the 3.10+ cpython > implementations. > > I've tested the code at the bottom of this message using a few docker > python images, and it appears there is a difference starting in 3.10.0 > > python3.8 > EXPECTED 256000 > ACTUAL 84533137 > python:3.9 > EXPECTED 256000 > ACTUAL 95311773 > python:3.10 (.8) > EXPECTED 256000 > ACTUAL 256000 > > just to see if there was a specific sub-version of 3.10 that added it > python:3.10.0 > EXPECTED 256000 > ACTUAL 256000 > > nope, from the start of 3.10 this is happening > > the only difference in the bytecode I see is 3.10 adds SETUP_LOOP and > POP_BLOCK around the for loop > > I don't see anything different in the long c code that I would expect > would cause this. > > AFAICT the inplace add is null for longs and so should revert to the > long_add that always creates a new integer in x_add > > another test > python:3.11 > EXPECTED 256000 > ACTUAL 256000 > > I'm not sure where the difference is at the moment. I didn't see anything > in the release notes given a quick glance. > > I do agree that you shouldn't depend on this unless you find a written > guarantee of the behavior, as it is likely an implementation quirk of some > kind > > --[code]-- > > import threading > > UPDATES = 1000 > THREADS = 256 > > vv = 0 > > def update_x_times( xx ): > for _ in range( xx ): > global vv > vv += 1 > > def main(): > tts = [] > for _ in range( THREADS ): > tts.append( threading.Thread( target = update_x_times, args = > (UPDATES,) ) ) > > for tt in tts: > tt.start() > > for tt in tts: > tt.join() > > print( 'EXPECTED', UPDATES * THREADS ) > print( 'ACTUAL ', vv ) > > if __name__ == '__main__': > main() > > On Sun, Feb 26, 2023 at 6:35 PM Jon Ribbens via Python-list < > python-list@python.org> wrote: > >> On 2023-02-26, Barry Scott wrote: >> > On 25/02/2023 23:45, Jon Ribbens via Python-list wrote: >> >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. >> > >> > No that is not true, and has never been true. >> > >> >:>>> def x(a): >> >:...a += 1 >> >:... >> >:>>> >> >:>>> dis.dis(x) >> > 1 0 RESUME 0 >> > >> > 2 2 LOAD_FAST0 (a) >> > 4 LOAD_CONST 1 (1) >> > 6 BINARY_OP 13 (+=) >> > 10 STORE_FAST 0 (a) >> > 12 LOAD_CONST 0 (None) >> > 14 RETURN_VALUE >> >:>>> >> > >> > As you can see there are 4 byte code ops executed. >> > >> > Python's eval loop can switch to another thread between any of them. >> > >> > Its is not true that the GIL provides atomic operations in python. >> >> That's oversimplifying to the point of falsehood (just as the opposite >> would be too). And: see my other reply in this thread just now - if the >> GIL isn't making "x += 1" atomic, something else is. >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > -- https://mail.python.org/mailman/listinfo/python-list
RE: Python 3.10 Fizzbuzz
Only sometimes. Is it an insult to suggest the question about what quotes to use is quite basic? Python has a wide variety of ways to make a string and if you have text that contains one kind of quote, you can nest it in the other kind. Otherwise, it really does not matter. And, yes, there are triply quoted strings as well as raw and formatted but to know about these things, you might have to read a manual. Since you won't, I provided an answer. The answer is that for the meaningless Fizzbuzz homework type of problem which is just ASCII text, it does not matter at all which kind of quote you use as long as what you use matches itself at the end of the string and as long as you use the ASCII versions, not the ones you might make in programs like WORD that have a pair for each. Oh, by the way, people here use lots of editors to deal with their code including versions derived from vi and emacs and MANY others, so many people here need to be told why you are asking some of your editing questions that do not at first seem to relate. We strive to focus here a bit more on using the language than on how to make your editor do tricks. -Original Message- From: Python-list On Behalf Of Hen Hanna Sent: Sunday, February 26, 2023 4:07 PM To: python-list@python.org Subject: Re: Python 3.10 Fizzbuzz On Monday, August 29, 2022 at 7:18:22 PM UTC-7, Paul Rubin wrote: > Just because. > > from math import gcd > def fizz(n: int) -> str: >match gcd(n, 15): > case 3: return "Fizz" > case 5: return "Buzz" > case 15: return "FizzBuzz" > case _: return str(n) > > for i in range(1,101): > print(fizz(i)) is there any reason to prefer"over' ? -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
I wanted to provide an example that your claimed atomicity is simply wrong, but I found there is something different in the 3.10+ cpython implementations. I've tested the code at the bottom of this message using a few docker python images, and it appears there is a difference starting in 3.10.0 python3.8 EXPECTED 256000 ACTUAL 84533137 python:3.9 EXPECTED 256000 ACTUAL 95311773 python:3.10 (.8) EXPECTED 256000 ACTUAL 256000 just to see if there was a specific sub-version of 3.10 that added it python:3.10.0 EXPECTED 256000 ACTUAL 256000 nope, from the start of 3.10 this is happening the only difference in the bytecode I see is 3.10 adds SETUP_LOOP and POP_BLOCK around the for loop I don't see anything different in the long c code that I would expect would cause this. AFAICT the inplace add is null for longs and so should revert to the long_add that always creates a new integer in x_add another test python:3.11 EXPECTED 256000 ACTUAL 256000 I'm not sure where the difference is at the moment. I didn't see anything in the release notes given a quick glance. I do agree that you shouldn't depend on this unless you find a written guarantee of the behavior, as it is likely an implementation quirk of some kind --[code]-- import threading UPDATES = 1000 THREADS = 256 vv = 0 def update_x_times( xx ): for _ in range( xx ): global vv vv += 1 def main(): tts = [] for _ in range( THREADS ): tts.append( threading.Thread( target = update_x_times, args = (UPDATES,) ) ) for tt in tts: tt.start() for tt in tts: tt.join() print( 'EXPECTED', UPDATES * THREADS ) print( 'ACTUAL ', vv ) if __name__ == '__main__': main() On Sun, Feb 26, 2023 at 6:35 PM Jon Ribbens via Python-list < python-list@python.org> wrote: > On 2023-02-26, Barry Scott wrote: > > On 25/02/2023 23:45, Jon Ribbens via Python-list wrote: > >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. > > > > No that is not true, and has never been true. > > > >:>>> def x(a): > >:...a += 1 > >:... > >:>>> > >:>>> dis.dis(x) > > 1 0 RESUME 0 > > > > 2 2 LOAD_FAST0 (a) > > 4 LOAD_CONST 1 (1) > > 6 BINARY_OP 13 (+=) > > 10 STORE_FAST 0 (a) > > 12 LOAD_CONST 0 (None) > > 14 RETURN_VALUE > >:>>> > > > > As you can see there are 4 byte code ops executed. > > > > Python's eval loop can switch to another thread between any of them. > > > > Its is not true that the GIL provides atomic operations in python. > > That's oversimplifying to the point of falsehood (just as the opposite > would be too). And: see my other reply in this thread just now - if the > GIL isn't making "x += 1" atomic, something else is. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: one Liner: Lisprint(x) --> (a, b, c) instead of ['a', 'b', 'c']
I so rarely need to save a list in python in a form acceptable to LISP but here
is a go with no visible recursion needed.
>>> nested = [1, 2, [3, 4, [5, 6, 7], 8], 9]
>>> print(nested)
[1, 2, [3, 4, [5, 6, 7], 8], 9]
# Just converting to a tuple does not change nested lists
>>> print(tuple(nested))
(1, 2, [3, 4, [5, 6, 7], 8], 9)
# But a function that typographically replaces [] with () needs no recursion
>>> def p2b(nested_list): return
>>> repr(nested_list).replace('[','(').replace(']',')')
>>> print(p2b(nested))
(1, 2, (3, 4, (5, 6, 7), 8), 9)
People who speak python well do not necessarily lisp.
-Original Message-
From: Python-list On
Behalf Of Hen Hanna
Sent: Sunday, February 26, 2023 4:54 AM
To: python-list@python.org
Subject: Re: one Liner: Lisprint(x) --> (a, b, c) instead of ['a', 'b', 'c']
On Saturday, February 25, 2023 at 11:45:12 PM UTC-8, Hen Hanna wrote:
> def Lisprint(x): print( ' (' + ', '.join(x) + ')' , '\n')
>
> a= ' a b c ? def f x if zero? x 0 1 '
> a += ' A B C ! just an example '
> x= a.split()
>
> print(x)
> Lisprint(x)
>
> ['a', 'b', 'c', '?', 'def', 'f', 'x', 'if', 'zero?', 'x', '0', '1', 'A', 'B',
> 'C', '!', 'just', 'an', 'example']
>
> (a, b, c, ?, def, f, x, if, zero?, x, 0, 1, A, B, C, !, just, an, example)
For nested lists impossible to improve upon P.Norvig's code
def Lisprint(x): print(lispstr(x))
def lispstr(exp):
"Convert a Python object back into a Lisp-readable string."
if isinstance(exp, list):
return '(' + ' '.join(map(lispstr, exp)) + ')'
else:
return str(exp)
a=' a b c '
x= a.split()
x += [['a', 'b', 'c']]
x += x
print(x)
Lisprint(x)
['a', 'b', 'c', ['a', 'b', 'c'], 'a', 'b', 'c', ['a', 'b', 'c']]
(a b c (a b c) a b c (a b c))
-- Without the commas, the visual difference
(concision) is striking !
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
On 2/26/2023 8:40 PM, MRAB wrote:
On 2023-02-26 16:56, Hen Hanna wrote:
On Sunday, February 26, 2023 at 6:41:01 AM UTC-8, Thomas Passin wrote:
On 2/25/2023 8:12 PM, Hen Hanna wrote: > 2. the rude guy ('dn')
hasn't offered a single word of comment that's directly relevant to
it. > > but he did offer related stuff which he thinks i
should be [grateful] for
Please let's stop the ad hominem messages. If someone doesn't like a
particular person's messages, send them to spam or don't read them.
If too many people start to get too rude or personal, remind the
whole list of the guidelines for respectful participation. If you
feel that someone's contribution was especially helpful in part
because it was concise and to the point, you could say that.
yes. let's stop...
If you (Thomas Passin) feel that someone's contribution was
especially helpful in part because it was
concise and to the point, you could say that.
and pls don't hesitate to reproduce such a
comment.
i'm sure a few others were also rude, but it was the rudest of them
all ('dn') that told me to read some [Code of Conduct] document.
Do not EVER do that again.
Another rude guy who "asked" me why i write in a Hard-to-read
way Why don't you at least also make a comment that's
On-Topic besides the insulting remark ?
so far, i think Paul Rubin's post (in another thread) was esp.
concise, informative, --- but he's also made a comment about
'shunting' beginners (questions) to a concentration camp, and
sounded a bit like a cold-hearted (or warm-hearted) Nazi officer /
scientist.
Oh dear. An example of Godwin's Law.
+1 Nicely put!
--
https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
On Sun, Feb 26, 2023 at 5:46 PM Chris Angelico wrote: > On Mon, 27 Feb 2023 at 12:44, MRAB wrote: > > Oh dear. An example of Godwin's Law. > > Yeah, is that finally enough to get this user banned ? I hope so > -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
On Mon, 27 Feb 2023 at 12:44, MRAB wrote: > Oh dear. An example of Godwin's Law. Yeah, is that finally enough to get this user banned already? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
On 2023-02-26 16:56, Hen Hanna wrote:
On Sunday, February 26, 2023 at 6:41:01 AM UTC-8, Thomas Passin wrote:
On 2/25/2023 8:12 PM, Hen Hanna wrote:
> 2. the rude guy ('dn') hasn't offered a single word of comment that's directly relevant to it.
> > but he did offer related stuff which he thinks i should be [grateful] for
Please let's stop the ad hominem messages. If someone doesn't like a
particular person's messages, send them to spam or don't read them. If
too many people start to get too rude or personal, remind the whole list
of the guidelines for respectful participation. If you feel that
someone's contribution was especially helpful in part because it was
concise and to the point, you could say that.
yes. let's stop...
If you (Thomas Passin) feel that someone's contribution was especially
helpful in part because it was
concise and to the point, you could say that.
and pls don't hesitate to reproduce such a comment.
i'm sure a few others were also rude, but it was the rudest of them all ('dn')
that told me to read some [Code of Conduct] document. Do not EVER
do that again.
Another rude guy who "asked" me why i write in a Hard-to-read way Why
don't you at least also make a comment that's On-Topic besides the insulting remark ?
so far, i think Paul Rubin's post (in another thread) was esp. concise,
informative, --- but he's also made a comment about 'shunting' beginners
(questions) to a concentration camp, and sounded a bit like a
cold-hearted (or warm-hearted) Nazi officer / scientist.
Oh dear. An example of Godwin's Law.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
On Mon, 27 Feb 2023 at 10:42, Jon Ribbens via Python-list wrote: > > On 2023-02-26, Chris Angelico wrote: > > On Sun, 26 Feb 2023 at 16:16, Jon Ribbens via Python-list > > wrote: > >> On 2023-02-25, Paul Rubin wrote: > >> > The GIL is an evil thing, but it has been around for so long that most > >> > of us have gotten used to it, and some user code actually relies on it. > >> > For example, with the GIL in place, a statement like "x += 1" is always > >> > atomic, I believe. But, I think it is better to not have any shared > >> > mutables regardless. > >> > >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. > >> Any replacement for the GIL would have to keep the former at least, > >> plus the fact that you can do hundreds of things like list.append(foo) > >> which are all effectively atomic. > > > > The GIL is most assuredly *not* an evil thing. If you think it's so > > evil, go ahead and remove it, because we'll clearly be better off > > without it, right? > > If you say so. I said nothing whatsoever about the GIL being evil. You didn't, but I was also responding to Paul's description that the GIL "is an evil thing". Apologies if that wasn't clear. > Yes, sure, you can make x += 1 not work even single-threaded if you > make custom types which override basic operations. I'm talking about > when you're dealing with simple atomic built-in types such as integers. > > > Here's the equivalent with just incrementing a global: > > > def thrd(): > > ... x += 1 > > ... > dis.dis(thrd) > > 1 0 RESUME 0 > > > > 2 2 LOAD_FAST_CHECK 0 (x) > > 4 LOAD_CONST 1 (1) > > 6 BINARY_OP 13 (+=) > > 10 STORE_FAST 0 (x) > > 12 LOAD_CONST 0 (None) > > 14 RETURN_VALUE > > > > > The exact same sequence: load, add, store. Still not atomic. > > And yet, it appears that *something* changed between Python 2 > and Python 3 such that it *is* atomic: I don't think that's a guarantee. You might be unable to make it break, but that doesn't mean it's dependable. In any case, it's not the GIL that's doing this. It might be a quirk of the current implementation of the core evaluation loop, or it might be something unrelated, but whatever it is, removing the GIL wouldn't change that; and it's certainly no different whether it's a global or an attribute of an object. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[Python-announce] ANN: Austin -- CPython frame stack sampler v3.5 is now available
I am delighted to announce the 3.5 release of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running in a production environment, with minimal impact on performance. https://github.com/P403n1x87/austin The Austin VS Code extension provides a smooth interactive profiling experience, with interactive flame graphs straight into the text editor to allow you to quickly jump to the source code with a simple click. You can find the extension on the Visual Studio Marketplace and install it directly from VS Code: https://marketplace.visualstudio.com/items?itemName=p403n1x87.austin-vscode To see how to make the best of Austin with VS Code to find and fix performance issues, check out this blog post, which shows you the editor extension in action on a real Python project: https://p403n1x87.github.io/how-to-bust-python-performance-issues.html Like the most recent releases, this new one also come with some performance improvements, this time in the shape of higher sampling rates in multiprocess mode. The interpreter detection has also been improved across all supported platforms, and the alternative format has been dropped. But the main new feature is the support for the new column-level location information that is built into Python 3.11 code objects. This additional information allows extracting finer-grained profiling data, down to the expression level. The VS Code extension has been improved to support this extra location data, which will be visualised in the form of source heat maps. More details about what's new and bug-fixes can be found in the change-log https://github.com/P403n1x87/austin/blob/master/ChangeLog Austin is a pure C application that has no dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin can be installed easily on the following platforms and from the following sources: Linux: - Snap Store - AUR - Conda Forge macOS: - Homebrew - Conda Forge Windows: - Chocolatey - Scoop An Austin docker image, based on the latest Ubuntu image, is also available from Docker Hub: https://hub.docker.com/r/p403n1x87/austin Austin is also simple to compile from sources as it only depends on the standard C library, if you don't have access to the above-listed sources. You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). Austin is a free and open-source project. A lot of effort goes into its development to ensure the best performance and that it stays up-to-date with the latest Python releases. If you find it useful, consider sponsoring this project on GitHub at https://github.com/sponsors/P403n1x87. All the best, Gabriele https://github.com/P403n1x87/austin;>Austin 3.5 - frame stack sampler for CPython. (26-Feb-23) ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
Re: Python 3.10 Fizzbuzz
Dang auto-correct... Should read ... double quotes around "strings" and single quotes around 'c'haracters ... On Sun, Feb 26, 2023, 6:28 PM Skip Montanaro wrote: > is there any reason to prefer"over' ? >> > > Not really. As an old C programmer for many years I used double > quotes"around "strings" and single word around 'c'haracters, because that's > what I was used to. (This was long before triple quoted strings appeared in > the language.) > > Aside: Given all the various ways to quote strings for display, it irks me > a bit to see repr() still use single quotes in all cases, which requires > display of single quotes to be escaped. (In similar fashion, it would be a > minor improvement in my mind if the repr() code used raw strings where they > would simplify the display.) > > Skip > >> -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz
> > is there any reason to prefer"over' ? > Not really. As an old C programmer for many years I used double quotes"around "strings" and single word around 'c'haracters, because that's what I was used to. (This was long before triple quoted strings appeared in the language.) Aside: Given all the various ways to quote strings for display, it irks me a bit to see repr() still use single quotes in all cases, which requires display of single quotes to be escaped. (In similar fashion, it would be a minor improvement in my mind if the repr() code used raw strings where they would simplify the display.) Skip > -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
> And yet, it appears that *something* changed between Python 2 and Python 3 such that it *is* atomic: I haven't looked, but something to check in the source is opcode prediction. It's possible that after the BINARY_OP executes, opcode prediction jumps straight to the STORE_FAST opcode, avoiding the transfer to the top of the virtual machine loop. That would (I think) avoid checks related to GIL release and thread switches. I don't guarantee that's what's going on, and even if I'm correct, I don't think you can rely on it. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Rob Cliffe should stop sending me rude email messages.
On Sun, Feb 26, 2023 at 3:49 PM Hen Hanna wrote: > > Rob Cliffe should stop sending me rude email messages. You should stop spamming this lists with with meaningless posts. -- https://mail.python.org/mailman/listinfo/python-list
Re: Rob Cliffe should stop sending me rude email messages.
[I replied to the list, but for some reason my posts don't always get through, so I'm replying to you separately.] i guess if you have anything useful to say you can do that again. Your comments about (not "int") (whch didn't get through, apparently) were among the few that were relevant. On Sunday, February 26, 2023 at 10:10:09 AM UTC-8, Hen Hanna wrote: > Rob Cliffe should stop sending me rude email messages. > > > At the very least, Rob Cliffe should stop sending me ANY email messages, if > he doesn't intend to an email i've sent him. At the very least,Rob Cliffeshould stop sending me ANY email messages, if he doesn't intend to respond to an email i've sent him. (he failed to respond to 2 (or 3) i've sent him) _ USENET Nazi said: Yes your questions do seem excessively frequent even here on Usenet yes. this puts me in such a difficult position i feel i have to post a few more just to show that i'm not folloiwng the Nazi's advice (or suggestion) or those of thisRob Cliffe -- https://mail.python.org/mailman/listinfo/python-list
Re: Vim (To move text-Lines between files) ___ :ab wt w! ~/temp.vi ___ :ab rt r ~/temp.vi
On Sunday, February 26, 2023 at 10:28:41 AM UTC-8, rbowman wrote: > On Sun, 26 Feb 2023 09:17:46 -0800 (PST), Hen Hanna wrote: > > > > To move text-Lines between files --- i do this (below) Maybe > > there's a better (or more standard) way, but i've been doing this for > > 30+ years, so i'll prob. keep doing it. > > > You can use the buffers. > > "a yy will add the current line to buffer a. > > "A 5 yy will add 5 lines to buffer a. Note the use of case. > > "a p will write the contents of buffer a to the other file. > > Note that buffer a does not interfere with using a for a bookmark. In > other words if you've marked an area with 'm a', "a y'a will put the > text from the current position to the bookmark in buffer a. > > Also note that "* p will insert the contents of the clipboard or copy the > text to the clipboard. I use that if I have files open in two different > gvim instances. thank you... that seems to work...i dont like to split the screen (into Panes) in Vim Select the text in visual mode, then press y to "yank" it into the buffer (copy) or d to "delete" it into the buffer (cut). Then you can :split to split your vim window up, and press p to paste in the yanked text. Write the file as normal. To close the split again, pass the split you want to close :q . _ USENET Nazi said: Yes your questions do seem excessively frequent even here on Usenet yes. Usenet-Nazis think they own the Usenet.- i'm so GLAD that they don't ! ! ! ** The Usenet-Nazi as in .. "The Soup Nazi" is the 116th episode of the NBC sitcom Seinfeld, which was the sixth episode of the seventh season. ... -- https://mail.python.org/mailman/listinfo/python-list
Rob Cliffe should stop sending me rude email messages.
Rob Cliffe should stop sending me rude email messages. At the very least, Rob Cliffe should stop sending me ANY email messages, if he doesn't intend to an email i've sent him. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz
On Monday, August 29, 2022 at 7:18:22 PM UTC-7, Paul Rubin wrote: > Just because. > > from math import gcd > def fizz(n: int) -> str: >match gcd(n, 15): > case 3: return "Fizz" > case 5: return "Buzz" > case 15: return "FizzBuzz" > case _: return str(n) > > for i in range(1,101): > print(fizz(i)) is there any reason to prefer"over' ? -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
On Sunday, February 26, 2023 at 6:41:01 AM UTC-8, Thomas Passin wrote:
> On 2/25/2023 8:12 PM, Hen Hanna wrote:
> > 2. the rude guy ('dn') hasn't offered a single word of comment that's
> > directly relevant to it.
> > > but he did offer related stuff which he thinks i should be
> > > [grateful] for
> Please let's stop the ad hominem messages. If someone doesn't like a
> particular person's messages, send them to spam or don't read them. If
> too many people start to get too rude or personal, remind the whole list
> of the guidelines for respectful participation. If you feel that
> someone's contribution was especially helpful in part because it was
> concise and to the point, you could say that.
yes. let's stop...
If you (Thomas Passin) feel that someone's contribution was especially
helpful in part because it was
concise and to the point, you could say that.
and pls don't hesitate to reproduce such a comment.
i'm sure a few others were also rude, but it was the rudest of them all ('dn')
that told me to read some [Code of Conduct] document. Do not EVER
do that again.
Another rude guy who "asked" me why i write in a Hard-to-read way Why
don't you at least also make a comment that's On-Topic besides the
insulting remark ?
so far, i think Paul Rubin's post (in another thread) was esp. concise,
informative, --- but he's also made a comment about 'shunting' beginners
(questions) to a concentration camp, and sounded a bit like a
cold-hearted (or warm-hearted) Nazi officer / scientist.
I think you can speed this up by building two sets and intersecting them:
from itertools import combinations
ww = "JSOYOMFUBELR SCDUARWDRLYE DASNAGEFERTY CLULOOTSCEHN USENEARSEYNE".split()
ss = set(''.join(s) for w in ww for s in combinations(w.lower(),6))
d6 = set(d.strip().lower() for d in open('/usr/share/dict/words') if len(d)==7)
print(ss & d6)
i too often use short Var names x, xx, w,ww,s,ss ..
and also long ones.
--
https://mail.python.org/mailman/listinfo/python-list
Re-indenting Python code in Vim
Re-indenting Lisp code is =%
and it works really well !
(define (foo x)
(dotimes (i 100)
(bar bar x)))
--- it doesn't work as well for Python code.
(doing 5==at the 1st line Re-indents only 3 lines)
for c in string.ascii_lowercase:
for xin Dict[tuple(sorted(cw))] :
print(cw, x , end=' ')
print('other stuff', x , end=' ')
PRSW=True
--
https://mail.python.org/mailman/listinfo/python-list
Re: Vim (To move text-Lines between files) ___ :ab wt w! ~/temp.vi ___ :ab rt r ~/temp.vi
On Sun, 26 Feb 2023 09:17:46 -0800 (PST), Hen Hanna wrote: > To move text-Lines between files --- i do this (below) Maybe > there's a better (or more standard) way, but i've been doing this for > 30+ years, so i'll prob. keep doing it. > You can use the buffers. "a yy will add the current line to buffer a. "A 5 yy will add 5 lines to buffer a. Note the use of case. "a p will write the contents of buffer a to the other file. Note that buffer a does not interfere with using a for a bookmark. In other words if you've marked an area with 'm a', "a y'a will put the text from the current position to the bookmark in buffer a. Also note that "* p will insert the contents of the clipboard or copy the text to the clipboard. I use that if I have files open in two different gvim instances. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
On 2023-02-26, Chris Angelico wrote: > On Sun, 26 Feb 2023 at 16:16, Jon Ribbens via Python-list > wrote: >> On 2023-02-25, Paul Rubin wrote: >> > The GIL is an evil thing, but it has been around for so long that most >> > of us have gotten used to it, and some user code actually relies on it. >> > For example, with the GIL in place, a statement like "x += 1" is always >> > atomic, I believe. But, I think it is better to not have any shared >> > mutables regardless. >> >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. >> Any replacement for the GIL would have to keep the former at least, >> plus the fact that you can do hundreds of things like list.append(foo) >> which are all effectively atomic. > > The GIL is most assuredly *not* an evil thing. If you think it's so > evil, go ahead and remove it, because we'll clearly be better off > without it, right? If you say so. I said nothing whatsoever about the GIL being evil. > As it turns out, most GIL-removal attempts have had a fairly nasty > negative effect on performance. The GIL is a huge performance boost. > > As to what is atomic and what is not... it's complicated, as always. > Suppose that x (or foo.x) is a custom type: Yes, sure, you can make x += 1 not work even single-threaded if you make custom types which override basic operations. I'm talking about when you're dealing with simple atomic built-in types such as integers. > Here's the equivalent with just incrementing a global: > def thrd(): > ... x += 1 > ... dis.dis(thrd) > 1 0 RESUME 0 > > 2 2 LOAD_FAST_CHECK 0 (x) > 4 LOAD_CONST 1 (1) > 6 BINARY_OP 13 (+=) > 10 STORE_FAST 0 (x) > 12 LOAD_CONST 0 (None) > 14 RETURN_VALUE > > The exact same sequence: load, add, store. Still not atomic. And yet, it appears that *something* changed between Python 2 and Python 3 such that it *is* atomic: import sys, threading class Foo: x = 0 foo = Foo() y = 0 def thrd(): global y for _ in range(1): foo.x += 1 y += 1 threads = [threading.Thread(target=thrd) for _ in range(50)] for t in threads: t.start() for t in threads: t.join() print(sys.version) print(foo.x, y) 2.7.5 (default, Jun 28 2022, 15:30:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] (64489, 59854) 3.8.10 (default, Nov 14 2022, 12:59:47) [GCC 9.4.0] 50 50 -- https://mail.python.org/mailman/listinfo/python-list
Vim (To move text-Lines between files) ___ :ab wt w! ~/temp.vi ___ :ab rt r ~/temp.vi
within Vim, do :smile ___ To move text-Lines between files --- i do this (below) Maybe there's a better (or more standard) way, but i've been doing this for 30+ years, so i'll prob. keep doing it. i have these in my .vimrc file. :ab qq q! :ab wt w! ~/temp.vi :ab rt r~/temp.vi So i can .. [1] from one file, do :.wt-- write 1 line to temp file :.,.+5 wt -- write 6 lines to temp file :.,'a wt -- write up to (and including) mark A to temp file [2] optionally edit the temp file [3] from another file, do the following to read (in) the temp file :rt > Yes your questions do seem excessively frequent even here on Usenet. > I have mostly been ignoring them after seeing the first few. what do you know about USENET ? i'm pretty sure i've been posting to USENET longer than you ... i'm also pretty sure that i've been programming longer than you... (but you may be faster and better.) -- https://mail.python.org/mailman/listinfo/python-list
Re: one Liner: Lisprint(x) --> (a, b, c) instead of ['a', 'b', 'c']
On Saturday, February 25, 2023 at 11:45:12 PM UTC-8, Hen Hanna wrote:
> def Lisprint(x): print( ' (' + ', '.join(x) + ')' , '\n')
>
> a= ' a b c ? def f x if zero? x 0 1 '
> a += ' A B C ! just an example '
> x= a.split()
>
> print(x)
> Lisprint(x)
>
> ['a', 'b', 'c', '?', 'def', 'f', 'x', 'if', 'zero?', 'x', '0', '1', 'A', 'B',
> 'C', '!', 'just', 'an', 'example']
>
> (a, b, c, ?, def, f, x, if, zero?, x, 0, 1, A, B, C, !, just, an, example)
For nested lists impossible to improve upon P.Norvig's code
def Lisprint(x): print(lispstr(x))
def lispstr(exp):
"Convert a Python object back into a Lisp-readable string."
if isinstance(exp, list):
return '(' + ' '.join(map(lispstr, exp)) + ')'
else:
return str(exp)
a=' a b c '
x= a.split()
x += [['a', 'b', 'c']]
x += x
print(x)
Lisprint(x)
['a', 'b', 'c', ['a', 'b', 'c'], 'a', 'b', 'c', ['a', 'b', 'c']]
(a b c (a b c) a b c (a b c))
-- Without the commas, the visual difference
(concision) is striking !
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
On 2023-02-26, Barry Scott wrote: > On 25/02/2023 23:45, Jon Ribbens via Python-list wrote: >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. > > No that is not true, and has never been true. > >:>>> def x(a): >:... a += 1 >:... >:>>> >:>>> dis.dis(x) > 1 0 RESUME 0 > > 2 2 LOAD_FAST 0 (a) > 4 LOAD_CONST 1 (1) > 6 BINARY_OP 13 (+=) > 10 STORE_FAST 0 (a) > 12 LOAD_CONST 0 (None) > 14 RETURN_VALUE >:>>> > > As you can see there are 4 byte code ops executed. > > Python's eval loop can switch to another thread between any of them. > > Its is not true that the GIL provides atomic operations in python. That's oversimplifying to the point of falsehood (just as the opposite would be too). And: see my other reply in this thread just now - if the GIL isn't making "x += 1" atomic, something else is. -- https://mail.python.org/mailman/listinfo/python-list
one Liner: Lisprint(x) --> (a, b, c) instead of ['a', 'b', 'c']
def Lisprint(x): print( ' (' + ', '.join(x) + ')' , '\n')
a=' a b c ? def f x if zero? x 0 1 '
a += ' A B C ! just an example '
x= a.split()
print(x)
Lisprint(x)
['a', 'b', 'c', '?', 'def', 'f', 'x', 'if', 'zero?', 'x', '0', '1', 'A', 'B',
'C', '!', 'just', 'an', 'example']
(a, b, c, ?, def, f, x, if, zero?, x, 0, 1, A, B, C, !, just, an, example)
--
https://mail.python.org/mailman/listinfo/python-list
Re: it seems like a few weeks ago... but actually it was more like 30 years ago that i was programming in C, and
On Wednesday, February 22, 2023 at 10:38:00 PM UTC-8, Greg Ewing wrote: > On 23/02/23 9:37 am, Hen Hanna wrote: > > for the first several weeks... whenever i used Python... all i could think > > ofwas this is really Lisp (inside) with a thin veil of > > Java/Pascal syntax.. > > > > - that everything is first converted (macro-expanded) into > > (intermediated) Lisp code, and then. > I once toyed with the idea of implementing a Python compiler > by translating it into Scheme and then feeding it to a Scheme > compiler. > > But I quickly realised that, although Scheme and Python are > both dynamically-typed languages, Python is way *more* dynamic > than Scheme. > > So without doing some very serious static analysis, the best > I could do would be just putting together calls to runtime > support routines that implement all the dynamic dispatching > that Python does for its operators, etc., and the result > wouldn't be much better than an interpreter. > > There are some similarities between Python and Lisp-family > languages, but really Python is its own thing. > > -- > Greg Scope (and extent ?) of variables is one reminder that Python is not Lisp fori in range(5): print( i ) . print( i ) ideally, after the FOR loop is done, the (local) var i should also disappear. (this almost caused a bug for me) Maybe in a future ver. of Python, it will be just like: (dotimes (i 5) (print i)) -- https://mail.python.org/mailman/listinfo/python-list
Re: 'dn' saying "Welcome (to the list)"
On Saturday, February 25, 2023 at 9:52:35 PM UTC-8, Chris Angelico wrote:
> On Sun, 26 Feb 2023 at 16:23, Hen Hanna wrote:
> >
> >
> > On Thursday, March 4, 2021 dn wrote:
> > > Hi, and welcome to the list.
> >
> >
> > note that this is the very same rude guy ('dn') who is apparently the
> > rudest of them all.
> >
> > note that this is the very same rude guy ('dn') who wants to shunt me away
> > to the TUTOR list.
> >
> > --- i guess i'd consider being TUTOR'ed by 'dn' (or someone like
> > it)
> > if i can be paid $1000 / hour for it.
> >
> >
> >
> > Have others noticed this too? (it's often the guy who says "Welcome"
> > that)
> >
> >
> > Whenever someone says "Welcome" to me (in this way), my alarm goes off.
> >
> >
> > - a good way to explain it (the Phenomenon) is... it's an
> > indication that he's itching to treat me as a Newbie... that he 's
> > salivating because he senses an opportunity to MANsplain and WHITEsplain
> > things to me.
> >
> Fine, I won't say "welcome to the list" to anyone in the future.
the rule of thumb is... [Don't say it ; show it ]
Maybe 10% of the time, ppl who say [Welcome to ...] are actually good
(welcoming) ppl.
--
https://mail.python.org/mailman/listinfo/python-list
RE: TypeError: can only concatenate str (not "int") to str
Alan, Good tack. By not welcoming someone who is paranoid about being welcomed you are clearly the right kind of welcoming! Kidding aside, you have a point about one of the barrage of messages probably not getting a great answer on your tutor forum. It is the MANY messages often about fairly simple aspects of python, taken together, that lead to the conclusion that this person is fairly new to python and still thinking about things from a lifetime of experience using other languages. I will say that at this point, it does not matter where they post as I cannot imagine anyone having to pay them $1,000/hour for the privilege of trying to tutor them. There are topics raised that can be informative and lead to good discussions amicably and as far as I can tell, many agree it would be nice if some "error" messages provided more detail and perhaps some eventually will. But as has been pointed out, these messages are only a small part of the python environment and lots of other tools are typically used to debug that do allow access to all kinds of details at breakpoints. I think many would be satisfied with some of the answers provided here and note, FEW OR NONE OF US here (or am I wrong) are necessarily in a position to make changes like this to the current or next versions of python. We are all users who take what we get and work with it or look for a way around things. The example used did not strike me as hard to figure out which of X/Y was an int/str and what their values were. More time is wasted demanding and debating a feature that is not there rather than solving the problem in other ways. In the interest of civility, I find removing myself sometimes works well. We are volunteers and I don't need to volunteer to help any particular person who does not seem to appreciate it. And if a forum fills up with nonsense so the signal is hard to find amid the noise, why bother contributing? Avi -Original Message- From: Python-list On Behalf Of Alan Gauld Sent: Sunday, February 26, 2023 4:15 AM To: python-list@python.org Subject: Re: TypeError: can only concatenate str (not "int") to str On 26/02/2023 00:54, Greg Ewing via Python-list wrote: > On 26/02/23 10:53 am, Paul Rubin wrote: >> I'm not on either list but the purpose of the tutor list is to shunt >> beginner questions away from the main list. I'm not sure that's why we set it up but it is certainly a large part of our remit. But protecting newbies from overly complex responses and covering wider topics (beyond pure Pyhon) is also a large part of our purpose. > There's a fundamental problem with tutor lists. They rely on > experienced people, the ones capable of answering the questions, to go > out of their way to read the tutor list -- something that is not of > personal benefit to them. In practice, the "tutors" tend to be split between folks who inhabit both lists and those who only interact on the tutor list. eg. I lurk here and only occasionally partake. But the problem with this particular thread is that, if directed to the tutor list, the OP would simply be told that "that's the way Python works". The tutor list is not for discussing language enhancements etc. It is purely about answering questions on how to use the language (and standard library) as it exists. (We also cover beginner questions about programming in general.) So this thread is most definitely in the right place IMHO. -- Alan G Tutor list moderator -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: TypeError: can only concatenate str (not "int") to str
On 2/25/2023 8:12 PM, Hen Hanna wrote:
2. the rude guy ('dn') hasn't offered a single word of comment that's
directly relevant to it.
> but he did offer related stuff which he
thinks i should be [grateful] for
Please let's stop the ad hominem messages. If someone doesn't like a
particular person's messages, send them to spam or don't read them. If
too many people start to get too rude or personal, remind the whole list
of the guidelines for respectful participation. If you feel that
someone's contribution was especially helpful in part because it was
concise and to the point, you could say that.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more efficient threading lock?
On 25/02/2023 23:45, Jon Ribbens via Python-list wrote: I think it is the case that x += 1 is atomic but foo.x += 1 is not. No that is not true, and has never been true. :>>> def x(a): :... a += 1 :... :>>> :>>> dis.dis(x) 1 0 RESUME 0 2 2 LOAD_FAST 0 (a) 4 LOAD_CONST 1 (1) 6 BINARY_OP 13 (+=) 10 STORE_FAST 0 (a) 12 LOAD_CONST 0 (None) 14 RETURN_VALUE :>>> As you can see there are 4 byte code ops executed. Python's eval loop can switch to another thread between any of them. Its is not true that the GIL provides atomic operations in python. Barry -- https://mail.python.org/mailman/listinfo/python-list
[Python-announce] Cython 3.0 beta 1 is released
Hi all, Cython 3.0 has left the alpha status – the first beta release is available from PyPI. https://cython.org/ https://pypi.org/project/Cython/ The changes in this release are huge – and the full list of improvements compared to the 0.29.x release series is entirely incredible. Cython 3.0 is better than any other Cython release before, in all aspects. It's much more Python, integrates better with C++, supports more Python implementations and configurations, provides many great new language features – it's faster, safer and easier to use. It's simply better. https://cython.readthedocs.io/en/latest/src/changes.html#beta-1-2023-02-25 What is Cython? In case you didn't hear about Cython before, it's the most widely used statically optimising Python compiler out there. It translates Python (2/3) code to C, and makes it as easy as Python itself to tune the code all the way down into fast native code. If you have any non-trivial Python application running, chances are you'll find some piece of Cython generated package in it. The development of the Cython 3.0 release series started all the way back in 2018, with the first branch commit happening on October 27, 2018. https://github.com/cython/cython/commit/c2de8efb67f80bff59975641aac387d652324e4e A list of Milestones along the way, and a long list of contributors: https://github.com/cython/cython/issues/4022#issuecomment-1404305257 Thank you to everyone who contributed. A couple of people have also joined in an effort to make the documentation reflect what this great new Cython has to offer. https://cython.readthedocs.io/en/latest/ Now, go and give it a try. We've taken great care to make the transition from Cython 0.29.x as smooth as possible, which was not easy given the large amount of changes, including some well-motivated breaking changes. We wanted to let all users benefit from this new release. Let us know how it works for you, and tell others about it. :) Have fun, Stefan ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
Re: TypeError: can only concatenate str (not "int") to str
On 26/02/2023 00:54, Greg Ewing via Python-list wrote: > On 26/02/23 10:53 am, Paul Rubin wrote: >> I'm not on either list but the purpose of the tutor list is to shunt >> beginner questions away from the main list. I'm not sure that's why we set it up but it is certainly a large part of our remit. But protecting newbies from overly complex responses and covering wider topics (beyond pure Pyhon) is also a large part of our purpose. > There's a fundamental problem with tutor lists. They rely on > experienced people, the ones capable of answering the questions, > to go out of their way to read the tutor list -- something that > is not of personal benefit to them. In practice, the "tutors" tend to be split between folks who inhabit both lists and those who only interact on the tutor list. eg. I lurk here and only occasionally partake. But the problem with this particular thread is that, if directed to the tutor list, the OP would simply be told that "that's the way Python works". The tutor list is not for discussing language enhancements etc. It is purely about answering questions on how to use the language (and standard library) as it exists. (We also cover beginner questions about programming in general.) So this thread is most definitely in the right place IMHO. -- Alan G Tutor list moderator -- https://mail.python.org/mailman/listinfo/python-list
Re: No module named _socket, on windows
On 2023-02-25 at 15:58:35 -0800, ofek shulberg wrote: > On Monday, January 4, 2010 at 9:19:21 PM UTC+2, Gabriel Genellina wrote: > > En Mon, 04 Jan 2010 14:24:22 -0300, louisJ escribi�: > > > I installed python 2.6 (from python.org) for windows XP, and then > > > Pylab. > > > When I type "import pylab" in a python shell it shows the error: > > > > > > ImportError: No module named _socket > > Open the Python command line, type the following lines, and tell us what > > happens: > > Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit > > (Intel)] on > > win32 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import socket > > >>> socket._socket > > > > > > -- > > Gabriel Genellina > > > hi Gabriel, > i have the same problem and also pip is not installed for some reason, what > can i do? Gabriel's post is thirteen years old and against a truly ancient version of Python (on Windows XP, no less). Please repost your question. Include the OS and the version of Python you're using, and a copy/paste of the error(s) you're receiving. -- https://mail.python.org/mailman/listinfo/python-list
