On Monday 22 March 2021 22:31:27 Richard Damon wrote:
> On 3/22/21 4:20 PM, Christian Gollwitzer wrote:
> > Am 22.03.21 um 16:03 schrieb Robert Latest:
> >> Chris Angelico wrote:
> >>> Cool thing is, nobody in Python needs to maintain anything here.
> >>
> >> That's great because I'm actually havi
On 3/22/21 4:20 PM, Christian Gollwitzer wrote:
> Am 22.03.21 um 16:03 schrieb Robert Latest:
>> Chris Angelico wrote:
>>> Cool thing is, nobody in Python needs to maintain anything here.
>>
>> That's great because I'm actually having trouble with sending log
>> messages over
>> the socket conectio
On 23/03/2021 10.00, Avi Gross via Python-list wrote:
> Speaking for myself, I am beyond tired of this topic, however informative
> parts have been.
+1
> I will say it is irrational to try to impose rationally across all possible
> languages, let alone people like me who often combine 3 or more
On 3/21/21 5:44 PM, Dan Stromberg wrote:
python3 -m pip install
Got it. Thanks a lot.
--
Tim
tj49.com
--
https://mail.python.org/mailman/listinfo/python-list
Thanks for the response. I will try to address your comments inline.
> I guess it should be a good idea to answer what's the scope of this
> project - is it research one or "production" one? If it's research one,
> why be concerned with the churn of over-modern CPython versions?
> Wouldn't it be b
> Yeah, that is old writing, so is probably less clear (no pun intended)
> than it should be. In frame_dealloc, Py_CLEAR is called for
> stack/register slots instead of just Py_XDECREF. Might not be
> necessary.
Also, the intent is not to change any semantics here. The
implementation of RETURN_VAL
> In the "Object Lifetime" section you say "registers should be cleared upon
> last reference". That isn't safe, since there can be hidden dependencies on
> side effects of __del__, e.g.:
>
> process_objects = create_pipeline()
> output_process = process_objects[-1]
> return output_pr
Speaking for myself, I am beyond tired of this topic, however informative
parts have been.
I will say it is irrational to try to impose rationally across all possible
languages, let alone people like me who often combine 3 or more language in
a single sentence when talking to others like myself wi
Am 22.03.21 um 16:03 schrieb Robert Latest:
Chris Angelico wrote:
Cool thing is, nobody in Python needs to maintain anything here.
That's great because I'm actually having trouble with sending log messages over
the socket conection you helped me with, would you mind having a look?
You misund
Benjamin Schollnick wrote:
> I’m sorry, but it’s as if he’s arguing for the sake of arguing. It’s
> starting to feel very unproductive, and unnecessary.
That was never five minutes just now!
robert
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Mar 23, 2021 at 5:16 AM Karen Shaeffer via Python-list
wrote:
>
> Hi Chris,
> Thanks for your comment.
>
> > Python doesn't work with UTF-8 encoded code points; it works with
> > Unicode code points. Are you looking for something that checks whether
> > something is a palindrome, or locate
Hi Chris,
Thanks for your comment.
> Python doesn't work with UTF-8 encoded code points; it works with
> Unicode code points. Are you looking for something that checks whether
> something is a palindrome, or locates palindromes within it?
>
> def is_palindrome(txt):
>return txt == txt[::-1]
>
>> That's not true for digraphs where there is a third, distinct and
>> different "title" case. I think the doc should state that the initial
>> character is converted to titlecase. A parenthentical statement that
>> titlecase is usually but not always equal to uppercase would be nice,
>> but the c
>> I guess it depends on what you mean by "character". In my mind, the
>> first character of string s is s[1], and I would then expect that
>>
>> s.title()[1] == s[1].upper()
>>
>
> I presume you mean [0], but no, that's not the case. A single
> character can titlecase to two characters, or to a
On Tue, Mar 23, 2021 at 2:28 AM Grant Edwards wrote:
> The document for str.title() states that the initial character of each
> word is converted to uppercase. My point is that for characters that
> remain single characters regardless of case that means (to me) that
>
> s.title()[0] == s[0].upp
On 2021-03-22, Chris Angelico wrote:
> On Tue, Mar 23, 2021 at 1:18 AM Grant Edwards
> wrote:
>
>> I guess it depends on what you mean by "character". In my mind, the
>> first character of string s is s[1], and I would then expect that
>>
>> s.title()[1] == s[1].upper()
>>
> I presume you mean [
Chris Angelico wrote:
> Cool thing is, nobody in Python needs to maintain anything here.
That's great because I'm actually having trouble with sending log messages over
the socket conection you helped me with, would you mind having a look?
Regards,
robert
--
https://mail.python.org/mailman/listi
> Chris Angelico wrote:
[Helpful stuff]
I'm actually trying to implement a SocketHandler for a Python logger. However,
I can't get my handler on the client side to send anything. Do I need to
subclass logging.SocketHandler and fill the various methods with meaning? The
documentation doesn't say s
On Tue, Mar 23, 2021 at 1:18 AM Grant Edwards wrote:
>
> On 2021-03-21, MRAB wrote:
>
> IMO, the doc is wrong.
>
> >> Hmm, maybe it's different in 3.10, but the docs I'm seeing look fine.
> >> But maybe there's a better way to word it for both of them.
> >
> > Python 3.9.2 (tags/v3.9.2:1a79785, F
On 2021-03-21, MRAB wrote:
IMO, the doc is wrong.
>> Hmm, maybe it's different in 3.10, but the docs I'm seeing look fine.
>> But maybe there's a better way to word it for both of them.
>
> Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64
> bit (AMD64)] on win32
> Type
Karsten Hilbert wrote:
> and life with that wart.
Perfectly willing to as long as everybody agrees it's a wart ;-)
robert
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Mar 23, 2021 at 1:01 AM Robert Latest via Python-list
wrote:
> I don't mind .title() being in Python. I would very much mind to be the person
> in charge of maintaining it and having to port it into new versions of Python,
> always keeping an eye on the evolution of Unicode or other standa
Chris Angelico wrote:
> There are a small number of characters which, when case folded, become
> more than one character. The sharp S from German behaves thusly:
>
"ß".upper(), "ß".lower(), "ß".casefold(), "ß".title()
> ('SS', 'ß', 'ss', 'Ss')
Now we're getting somewhere. I'm a native German
Chris Angelico wrote:
>
> Hmm, your formatting's messed up, but the code looks fine to me. (Be aware
> that you seem to have a "selr" where it should be "self".)
Didn't catch that because my program didn't even get to that point ;-)
>
>> However, when I try to send somthing to that socket, I get
On Mon, Mar 22, 2021 at 9:11 PM Robert Latest via Python-list
wrote:
>
> Hello,
>
> I'm trying to set up a server that receives data on a Unix domain socket using
> the code below.
>
> import os from socketserver import UnixStreamServer, StreamRequestHandler
>
> SOCKET = '/tmp/test.socket'
>
> cla
On Mon, Mar 22, 2021 at 9:21 PM Robert Latest via Python-list
wrote:
>
> Chris Angelico wrote:
> > If you still, after all these posts, have not yet understood that
> > title-casing *a single character* is a significant thing,
>
> I must admit I have no idea what title-casing even is, but I'm eage
Robert,
I certainly see your point.
> My only issue is that I completely fail to see how this function would be
> useful enough to warrant the inclusion into the *core* of a general-purpose
> language, including its misleading name.
But that’s where we have to disagree.
Sure, the name cold be
Chris Angelico wrote:
> If you still, after all these posts, have not yet understood that
> title-casing *a single character* is a significant thing,
I must admit I have no idea what title-casing even is, but I'm eager to learn.
The documentation only talks about "words" and "first characters" and
Hello,
I'm trying to set up a server that receives data on a Unix domain socket using
the code below.
import os from socketserver import UnixStreamServer, StreamRequestHandler
SOCKET = '/tmp/test.socket'
class Handler(StreamRequestHandler):
def handle(self): data = selr.rfile.read() print(
On Mon, Mar 22, 2021 at 8:26 PM Robert Latest via Python-list
wrote:
>
> Benjamin Schollnick wrote:
> >
> >> I agree with everything you say. Especially the open source part. But
> >> wouldn't you agree that .title() with all its arbitrary specificity to
> >> appear in the very core of a general p
Am Mon, Mar 22, 2021 at 09:22:51AM + schrieb Robert Latest via Python-list:
> >> I agree with everything you say. Especially the open source part. But
> >> wouldn't you agree that .title() with all its arbitrary specificity to
> >> appear in the very core of a general purpose language is quite
Grant Edwards wrote:
> On 2021-03-20, Robert Latest via Python-list wrote:
>> Mats Wichmann wrote:
>>> The problem is that there isn't a standard for title case,
>>
>> The problem is that we owe the very existence of the .title() method to too
>> much weed being smoked during Python development. I
Benjamin Schollnick wrote:
>
>> I agree with everything you say. Especially the open source part. But
>> wouldn't you agree that .title() with all its arbitrary specificity to
>> appear in the very core of a general purpose language is quite an oddity?
>
> No, because it book ends the issue.
>
> Up
33 matches
Mail list logo
