Re: .title() - annoying mistake

[Robert Latest via Python-list]

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.
>
> Upper - Converts everything to uppercase Lower - Converts everything to
> lowercase
>
> Title - Covers the cases in-between upper/lower.  

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. The fact that the function's behavior
is correctly documented doesn't make its very existence less bewildering to me.
Consider this function:

def add_seventeen(n): '''Return n with 16.8 added''' return n + 16.8

It's like .title(): It does almost the thing its name suggests, it is correctly
documented, it is useful to anybody who happens to want 16.8 added to numbers,
and it might erroneously be used by someone who wants exactly 17 added and
didn't bother to read the docs.

> And as I mentioned the sheer amount of work that would be needed would
> probably cover a phd dissertation or more…  It’s a huge problem set to
> respect one language, let alone all languages.  

And that's why I believe that such a function should be delegated to a natural
language-processing library and not the core of Python.

> So the only answer is to not respect the languages, and leave that up to a
> later implementation or for someone else to assist in adding in support.

And that too.

> Heck, how do we prevent it from titlecasing abbreviations?  (This is plain
> text not XML….  If it was XML it would be easy!)

And that too.

BTW I have no beef with the person who invented .title() nor with anybody who
uses it. I know that everybody can join the Python development community and
propose the removal of .title() and the inclusion of add_seventeen(). That
said, I doubt that .title() would make it into Python today if it weren't there
already. I'm having fun with this.

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

Re: .title() - annoying mistake

[Robert Latest via Python-list]

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. It makes specific
>> assumptions about a specific use case of one specific language. It doesn't
>> get more idiotic, frankly.
>
> Ah, you've never used PHP then?
>
> I haven't checked but it's a fair bit that PHP has 3-4 different built-in
> ways to do it, and they're all broken in interestingly unpredictable ways.

I believe that 100%. PHP is the reason I switched to Python/WSGI, and I'm
loving it. 

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

Re: .title() - annoying mistake

[Karsten Hilbert]

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 an oddity?
> >
> > No, because it book ends the issue.
> >
> > Upper - Converts everything to uppercase Lower - Converts everything to
> > lowercase
> >
> > Title - Covers the cases in-between upper/lower.
>
> 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. The fact that the function's behavior
> is correctly documented doesn't make its very existence less bewildering to 
> me.

Its naming may be unfortunate, its existence may be
bewildering. However, it's now there, and for historical
reasons, supposedly.

It won't be removed or renamed in all likelihood. The best
one can do is to suggest a documentation patch (not fix)
like so:

The algorithm uses a simple language-independent

[...] and context-naive, not locale related, [...]

definition of a word [...]

and life with that wart.

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

Re: .title() - annoying mistake

[Chris Angelico]

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 purpose language is quite an oddity?
> >
> > No, because it book ends the issue.
> >
> > Upper - Converts everything to uppercase Lower - Converts everything to
> > lowercase
> >
> > Title - Covers the cases in-between upper/lower.
>
> 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. The fact that the function's behavior
> is correctly documented doesn't make its very existence less bewildering to 
> me.
> Consider this function:
>
> def add_seventeen(n): '''Return n with 16.8 added''' return n + 16.8
>
> It's like .title(): It does almost the thing its name suggests, it is 
> correctly
> documented, it is useful to anybody who happens to want 16.8 added to numbers,
> and it might erroneously be used by someone who wants exactly 17 added and
> didn't bother to read the docs.

If you still, after all these posts, have not yet understood that
title-casing *a single character* is a significant thing, then please
do not continue to complain about language design. Without this
method, how do you correctly title-case one character? What do you
use? upper()? lower()? casefold()?

> BTW I have no beef with the person who invented .title() nor with anybody who
> uses it. I know that everybody can join the Python development community and
> propose the removal of .title() and the inclusion of add_seventeen(). That
> said, I doubt that .title() would make it into Python today if it weren't 
> there
> already. I'm having fun with this.
>

I'm glad you're having fun, because being wrong can be a lot of unfun sometimes.

I'm done arguing with you. You're a brick wall and you refuse to
comprehend Unicode. The method was not invented for ASCII.

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

How to set up a 'listening' Unix domain socket

[Robert Latest via Python-list]

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(data)

if os.path.exists(SOCKET): os.unlink(SOCKET) with UnixStreamServer(SOCKET,
Handler) as server: server.serve_forever()


However, when I try to send somthing to that socket, I get this error message:

$ echo "Hello" | socat - UNIX-SENDTO:/tmp/test.socket 2021/03/22 11:03:22
socat[2188] E sendto(5, 0x55a22f414990, 6, 0, AF=1 "/tmp/test.socket", 18):
Protocol wrong type for socket

I don't understand that error. Here's /tmp/test.socket:

$ stat /tmp/test.socket
  File: ‘/tmp/test.socket’
  Size: 0   Blocks: 0  IO Block: 4096   socket
Device: fd00h/64768dInode: 201443577   Links: 1
Access: (0775/srwxrwxr-x)  Uid: ( 1001/  dh)   Gid: ( 1001/  dh)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2021-03-22 09:47:49.516298102 +0100
Modify: 2021-03-22 09:47:49.516298102 +0100
Change: 2021-03-22 09:47:49.516298102 +0100
 Birth: -

Sadly all examples I can find on the web are for TCP sockets, not Unix domain.

Any tips?
robert
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: .title() - annoying mistake

[Robert Latest via Python-list]

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
"remaining characters." So a single character gets converted to uppercase,
whatever that may mean in the context of .title(). The .upper() method is
different in that it only applies to "cased" characters, so .title() may or may
not work differently on single characters. 

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

Re: .title() - annoying mistake

[Benjamin Schollnick]

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 a bit less “misleading”, I guess we could petition to 
have it renamed to:

def nonlanguage_aware_title or  def 
title_but_not_language_aware

But I’m sorry for the majority of us, we haven’t even realized that title 
wasn’t language aware.   That has to tell you something (mainly that we’ve 
never hit these problems).  

Now that doesn’t diminish your issue here.  

But you’re a programmer, people have already suggested someway to work around 
this with RE.

The other python specific might be to actually SPLIT on the ` symbol, title 
each segment returning from split, and the JOIN them together again.

Regarding the issue of THE in an actual title, I’d suggest that RE would be the 
best solution for that, it should be easy enough to come up with RE that’ll 
work for word “xxx The xxx” and convert it to “xxx the xxx”.  

> The fact that the function's behavior
> is correctly documented doesn't make its very existence less bewildering to 
> me.

Okay, I don’t recall you actually accepting at how large of a problem you are 
asking title to address.

The standard library is not going to fix and solve everything, like Apple I 
would expect them to target ~90% of the functionality, and then let people grow 
and expand on it’s functionality.  (Sort of like my CSV wrapper)

title is roughly comparable to PHP’s ucwords.

Wow, perl takes the prize though, it’s called ucwords.

$foo = 'hello world!';
$foo = ucwords($foo); // Hello World!

$bar = 'HELLO WORLD!';
$bar = ucwords($bar); // HELLO WORLD!
$bar = ucwords(strtolower($bar)); // Hello World!

perl appears to only manipulate the characters that it’s changing, so if the 
string is already uppercase, then it’ll just look like the entire string is 
uppercase when it’s done.  

So honestly that’s a mostly useless function if you need to pass a lowercase 
string into it.

What’s in common here?  both perl and php also seem to take the ` as a word 
separator.  

Neither of them appear to be language aware.

> Consider this function:
> 
> def add_seventeen(n): '''Return n with 16.8 added''' return n + 16.8
> 
> It's like .title(): It does almost the thing its name suggests, it is 
> correctly
> documented, it is useful to anybody who happens to want 16.8 added to numbers,
> and it might erroneously be used by someone who wants exactly 17 added and
> didn't bother to read the docs.

And would be laughed at significantly.  

I agree with your example, but I don’t consider it to be equivalent.  

title does at first, and second glance work as expected.  You have 
significantly higher expectations than we do, evidently.

At minimum, what I would suggest is come up with some test case examples, and 
toss that over to the python dev team.  Show them that this isn’t working as 
you expect, and see what they say.  

While there might be a few of the python developers on this list, I doubt it.  
Instead bring this up in a productive manner.  Show the harm, and then show a 
solution.  A Proposed change, an alternative framework.

We can’t solve the problem, but if you present it properly, then maybe you can 
be part of the solution.

> 
>> And as I mentioned the sheer amount of work that would be needed would
>> probably cover a phd dissertation or more…  It’s a huge problem set to
>> respect one language, let alone all languages.  
> 
> And that's why I believe that such a function should be delegated to a natural
> language-processing library and not the core of Python.

I have to disagree.  While I might expect a better version in a natural 
language processing library, every programming language that I’m aware of 
except for BASIC, offers an equivalent to title, as long as they offer an 
equivalent to upper and lower.

Why should python not offer title in light of this?

> said, I doubt that .title() would make it into Python today if it weren't 
> there
> already. I'm having fun with this.

Ah, so while being a bit serious, I’m reading a bit too much into this.  

At this point, it’s become an interesting thought experiment for you.  

Good luck,

- Benjamin


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

Re: .title() - annoying mistake

[Chris Angelico]

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 eager to learn.

Now that's an attitude I like to see :)

> The documentation only talks about "words" and "first characters" and
> "remaining characters." So a single character gets converted to uppercase,
> whatever that may mean in the context of .title(). The .upper() method is
> different in that it only applies to "cased" characters, so .title() may or 
> may
> not work differently on single characters.
>

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')
>>> "ẞ".upper(), "ẞ".lower(), "ẞ".casefold(), "ẞ".title()
('ẞ', 'ß', 'ss', 'ẞ')

Serbian has another, although it can often be written with two
individual characters:

>>> "DŽ".upper(), "DŽ".lower(), "DŽ".casefold(), "DŽ".title()
('DŽ', 'dž', 'dž', 'Dž')
>>> ["U+%04X" % ord(x) for x in _]
['U+01C4', 'U+01C6', 'U+01C6', 'U+01C5']

Even in text that's in the Latin script (the one we use with English),
there are some ligatures that behave differently when titlecased:

>>> "fi".upper(), "fi".lower(), "fi".casefold(), "fi".title()
('FI', 'fi', 'fi', 'Fi')
>>> [" ".join("U+%04X" % ord(c) for c in x) for x in _]
['U+0046 U+0049', 'U+FB01', 'U+0066 U+0069', 'U+0046 U+0069']

Each of these inputs is a single character; some of them have
single-character outputs (and in the case of U+01C5, that's a specific
character that is exclusively titlecased), others have multiple.

The neat thing about Unicode is that you don't have to worry about
exactly which characters behave in which ways. You get methods that do
precisely what you need, as long as you choose the right method. For
case insensitive comparisons, there's casefold(), which is most
commonly the same as lower(), but not always; to find out if
something's a digit, use isdigit(); to fracture something into lines,
use splitlines(). They're all aware of the entire Unicode range, and
they'll reliably work even if future versions of Unicode introduce
more characters (although you might have to wait for Python to be
updated).

The documentation sometimes shorthands things with terms like "upper
case" and "lower case", but that's partly because being pedantically
correct in a docstring doesn't actually help anything, and the code
itself IS correct.

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

Re: How to set up a 'listening' Unix domain socket

[Chris Angelico]

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'
>
> class Handler(StreamRequestHandler):
>
> def handle(self): data = selr.rfile.read() print(data)
>
> if os.path.exists(SOCKET): os.unlink(SOCKET) with UnixStreamServer(SOCKET,
> Handler) as server: server.serve_forever()

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".)

> However, when I try to send somthing to that socket, I get this error message:
>
> $ echo "Hello" | socat - UNIX-SENDTO:/tmp/test.socket 2021/03/22 11:03:22
> socat[2188] E sendto(5, 0x55a22f414990, 6, 0, AF=1 "/tmp/test.socket", 18):
> Protocol wrong type for socket
>

Not familiar with socat, but here's some simple Python code to trigger
your server:

>>> import socket
>>> sock = socket.socket(socket.AF_UNIX)
>>> sock.connect("/tmp/test.socket")
>>> sock.send(b"Hello, world")
12
>>> sock.close()
>>>

Once you close the socket, the request handler should respond.

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

Re: How to set up a 'listening' Unix domain socket

[Robert Latest via Python-list]

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 this error
>> message:
>>
>> $ echo "Hello" | socat - UNIX-SENDTO:/tmp/test.socket 2021/03/22 11:03:22
>> socat[2188] E sendto(5, 0x55a22f414990, 6, 0, AF=1 "/tmp/test.socket", 18):
>> Protocol wrong type for socket
>>
>
> Not familiar with socat, but here's some simple Python code to trigger your
> server:
>
 import socket sock = socket.socket(socket.AF_UNIX)
 sock.connect("/tmp/test.socket") sock.send(b"Hello, world")
> 12
 sock.close()


Works perfectly, thanks! I'm probably not using socat right.

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

Re: .title() - annoying mistake

[Robert Latest via Python-list]

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 speaker and I can tell you
that this doesn't happen in the real world, simply because 'ß' never appears at
the beginning of a word and thus is never "title cased". The only occurence of
uppercase 'ß' is in all-caps text, which Python handles properly:

'bißchen'.upper()
'BISSCHEN'

...that is, properly until 2008, when the capital 'ß' was officially introduced
into German ortography:

https://en.wikipedia.org/wiki/%C3%9F#Capital_form
"Traditionally, ß did not have a capital form, although some type designers
introduced de facto capitalized variants of ß. In 2017, the Council for German
Orthography ultimately adopted capital ß, ẞ, into German orthography, ending a
long orthographic debate.[3] [...] The capital variant (U+1E9E ẞ LATIN CAPITAL
LETTER SHARP S) was encoded by ISO 10646 in 2008." So Python 3.6.8 is about 12
years behind.

As a German I also appreciate the reduced occurence of the letter combination
'SS'.

That said, the concept of "title casing" doesn't even exist in German. Titles
are spelt just like any regular sentence. I know only two definitions of the
concept "title case":

1) From Wikipedia
"Title case or headline case is a style of capitalization used for rendering
the titles of published works or works of art in English. [...]"

2) From Python (paraphrased):
"Perform an arbitrary (but defined) operation on the characters of a string."

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 standards (see
above).

It probably just comes down to me not being able to conjure up a single
sensible use case for .title() as well as the whole concept of "title casing"
in the context of a programming language.

> The neat thing about Unicode is 

[many things]

> The documentation sometimes shorthands things with terms like "upper
> case" and "lower case", but that's partly because being pedantically
> correct in a docstring doesn't actually help anything, and the code
> itself IS correct.

...but hard to maintain and useless. I just love to hate .title() ;-)

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

Re: .title() - annoying mistake

[Chris Angelico]

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 standards (see
> above).
>
> It probably just comes down to me not being able to conjure up a single
> sensible use case for .title() as well as the whole concept of "title casing"
> in the context of a programming language.
>
> > The neat thing about Unicode is
>
> [many things]
>
> > The documentation sometimes shorthands things with terms like "upper
> > case" and "lower case", but that's partly because being pedantically
> > correct in a docstring doesn't actually help anything, and the code
> > itself IS correct.
>
> ...but hard to maintain and useless. I just love to hate .title() ;-)
>

Cool thing is, nobody in Python needs to maintain anything here. It's
all built on top of the published Unicode data files. It's simply a
matter of updating to the latest version of the Unicode standard! :)

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

Re: .title() - annoying mistake

[Robert Latest via Python-list]

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

Re: .title() - annoying mistake

[Grant Edwards]

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 "help", "copyright", "credits" or "license" for more information.
 help(str.title)
> Help on method_descriptor:
>
> title(self, /)
>  Return a version of the string where each word is titlecased.
>
>  More specifically, words start with uppercased characters and
>  all remaining cased characters have lower case.
>
> '\N{LATIN CAPITAL LETTER DZ}', '\N{LATIN SMALL LETTER DZ}' and '\N{LATIN 
> CAPITAL LETTER D WITH SMALL LETTER Z}' are all digraphs, so is it 
> correct to say that .title() uppercases the first character? Kind of.

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()

--
Grant


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

Re: .title() - annoying mistake

[Chris Angelico]

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, Feb 19 2021, 13:44:55) [MSC v.1928 64
> > bit (AMD64)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
>  help(str.title)
> > Help on method_descriptor:
> >
> > title(self, /)
> >  Return a version of the string where each word is titlecased.
> >
> >  More specifically, words start with uppercased characters and
> >  all remaining cased characters have lower case.
> >
> > '\N{LATIN CAPITAL LETTER DZ}', '\N{LATIN SMALL LETTER DZ}' and '\N{LATIN
> > CAPITAL LETTER D WITH SMALL LETTER Z}' are all digraphs, so is it
> > correct to say that .title() uppercases the first character? Kind of.
>
> 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 single character
that isn't the same as if you uppercase or lowercase it. See examples
in previous post.

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

Re: How to set up a 'listening' Unix domain socket

[Robert Latest via Python-list]

> 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 so.

I've noticed that when the server is not running, logging.SocketHandler creates
the socket. I don't understand why it would; isn't it the server's job to
create the socket?

## CLIENT 

import socket
import pickle
from logging import getLogger
from logging.handlers import SocketHandler

SOCKET = '/tmp/test.socket'

# This doesn't send anything to the socket
_log = getLogger(__name__)
_log.addHandler(SocketHandler(None, SOCKET))
_log.error('Logging something')

# String gets sent to socket
sock = socket.socket(socket.AF_UNIX)
sock.connect(SOCKET)
sock.send(b"Hello, world")
sock.close()

# Pickled object works fine
sock = socket.socket(socket.AF_UNIX)
sock.connect(SOCKET)
sock.send(pickle.dumps(dict(a=1)))
sock.close()


## SERVER 

import os
import pickle
from socketserver import UnixStreamServer, StreamRequestHandler

SOCKET = '/tmp/test.socket'

class Handler(StreamRequestHandler):

def handle(self):
data = self.rfile.read()
try:
obj = pickle.loads(data)
except:
print('Unpickled: ', data)
else:
print('Pickled: ', type(obj))

if os.path.exists(SOCKET):
os.unlink(SOCKET)
with UnixStreamServer(SOCKET, Handler) as server:
server.serve_forever()

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

Re: .title() - annoying mistake

[Robert Latest via Python-list]

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/listinfo/python-list

Re: .title() - annoying mistake

[Grant Edwards]

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 [0],

Yes.

> but no, that's not the case. A single character can titlecase to two
> characters, or to a single character that isn't the same as if you
> uppercase or lowercase it. See examples in previous post.

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].upper()

or for a single character string

  s.title() == s.upper()

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 current statement is obsolete and not correct in all, um...
cases.

--
Grant


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

Re: .title() - annoying mistake

[Chris Angelico]

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].upper()
>
> or for a single character string
>
>   s.title() == s.upper()
>
> 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 current statement is obsolete and not correct in all, um...
> cases.

Fair enough, but the trouble is that getting too pedantic in a
docstring just makes it read like IBM documentation. :)

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

Re: .title() - annoying mistake

[Benjamin Schollnick]

>> 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 single character
> that isn't the same as if you uppercase or lowercase it. See examples
> in previous post.

Or Kanji, etc.  Where a single character can represent more than one in a 
different unicode standard, as I understand. 

- Benjamin

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

Re: .title() - annoying mistake

[Benjamin Schollnick]

>> 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 current statement is obsolete and not correct in all, um...
>> cases.
> 
> Fair enough, but the trouble is that getting too pedantic in a
> docstring just makes it read like IBM documentation. :)

And actually conversely makes it harder to keep updating, because you’ll need 
to document every and all edge-cases, and then need to know when one of those 
edge cases breaks, etc.  

The core concept is documented, and it’s pretty straight-forward.  

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.

- Benjamin


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

Re: .title() - annoying mistake

[Karen Shaeffer via Python-list]

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]
> 
> Easy.

Of course, its easy. Its a pythonic idiom! But it doesn’t work. And you know 
that. You even explained a few reasons why it doesn’t work below. There are 
many more instances of strings that do not work. Here are two:

idx = 6A man, a plan, a canal: Panama   is_palindrome() = False
idx = 17ab́cdeedcb́a   is_palindrome() = False

The palindrome isn’t worth any more time. It isn’t even a good example.

In my experience processing unstructured, multilingual text, you encounter a 
wide array of variances in both the text and in the encoding details, including 
outright errors. You have to account for all of them, because 99.99% of that 
text is valuable to you.

The key idea: If you care about the details, working with unstructured 
multi-lingual text is complicated. There are no easy solutions.


> 
> Efficiently finding substring palindromes would be a bit harder, but
> that'd be true even if you restricted it to ASCII. The advantage of
> Python's way of doing it is that, if you have a method that would work
> with ASCII bytes, the exact same thing will work with a Unicode
> string.
> 
> There's another big wrinkle not touched here, and that's what to do
> with combining characters. Python makes it easy to normalize text as
> much as is possible, and an NFC normalization would help a lot, but
> it's not going to do everything. So you may want to first define a
> proper way to split a string into whatever you're defining a character
> to be, and that's a very difficult problem, regardless of programming
> language. For example, Arabic text changes in visual shape when
> letters are next to each other, and Greek has two different forms for
> the letter sigma (U+03C2 and U+03C3) - should those distinctions
> affect palindromminess? What about ligatures - is U+FB01 "fi" a single
> character, or should it be matched by "if" on the other end?
> 
> What part of this is trivial in Go?

Go is simpler than Python. Both languages have the capabilities to solve any 
text processing problem. I’m still learning Go, so I can’t really say more.

Personally, I like Python for text processing. You can usually get satisfactory 
results very quickly for most of the input space. And if you don’t care about 
all the gotchas, then you are good to go.

I have no more time for this. Thanks for your comment. I learned a little 
reading the long thread dealing with .title(). (chuckles ;)

Humbly,
Karen


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

Re: .title() - annoying mistake

[Chris Angelico]

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 locates palindromes within it?
> >
> > def is_palindrome(txt):
> >return txt == txt[::-1]
> >
> > Easy.
>
> Of course, its easy. Its a pythonic idiom! But it doesn’t work. And you know 
> that. You even explained a few reasons why it doesn’t work below. There are 
> many more instances of strings that do not work. Here are two:
>
> idx = 6A man, a plan, a canal: Panama   is_palindrome() = False
> idx = 17ab́cdeedcb́a   is_palindrome() = False
>
> The palindrome isn’t worth any more time. It isn’t even a good example.
>
> In my experience processing unstructured, multilingual text, you encounter a 
> wide array of variances in both the text and in the encoding details, 
> including outright errors. You have to account for all of them, because 
> 99.99% of that text is valuable to you.
>
> The key idea: If you care about the details, working with unstructured 
> multi-lingual text is complicated. There are no easy solutions.
>
>
> >
> > Efficiently finding substring palindromes would be a bit harder, but
> > that'd be true even if you restricted it to ASCII. The advantage of
> > Python's way of doing it is that, if you have a method that would work
> > with ASCII bytes, the exact same thing will work with a Unicode
> > string.
> >
> > There's another big wrinkle not touched here, and that's what to do
> > with combining characters. Python makes it easy to normalize text as
> > much as is possible, and an NFC normalization would help a lot, but
> > it's not going to do everything. So you may want to first define a
> > proper way to split a string into whatever you're defining a character
> > to be, and that's a very difficult problem, regardless of programming
> > language. For example, Arabic text changes in visual shape when
> > letters are next to each other, and Greek has two different forms for
> > the letter sigma (U+03C2 and U+03C3) - should those distinctions
> > affect palindromminess? What about ligatures - is U+FB01 "fi" a single
> > character, or should it be matched by "if" on the other end?
> >
> > What part of this is trivial in Go?
>
> Go is simpler than Python. Both languages have the capabilities to solve any 
> text processing problem. I’m still learning Go, so I can’t really say more.
>
> Personally, I like Python for text processing. You can usually get 
> satisfactory results very quickly for most of the input space. And if you 
> don’t care about all the gotchas, then you are good to go.
>
> I have no more time for this. Thanks for your comment. I learned a little 
> reading the long thread dealing with .title(). (chuckles ;)
>

Hey, you're the one who brought up palindrome testing as a difficult
problem in Python :) Your post implied that it was easier in Go, and I
can't see that that's possible.

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

Re: .title() - annoying mistake

[Robert Latest via Python-list]

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

Re: .title() - annoying mistake

[Christian Gollwitzer]

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 misunderstood the "here".

(native German as well, but I think it means "for keeping .title() up to 
date)


I agree with Chris that .title() can be useful for "title-casing" a 
single character, whatever that means. It should be documented, though, 
that it is not suitable to title-case a string, not even in English.


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

RE: .title() - annoying mistake

[Avi Gross via Python-list]

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 with a dynamic to
nonsensical grammar. Try capitalizing someone's name when they insist on
being known by a purely numerical name like ..., or just 7 of 9 or even
!@zq. 

So, yes, a purist might want a truly comprehensive piece of code larger than
say all the code in Microsoft WORD, that first figures out what language
might be used and uses locale and guesswork to even try to narrow down that
the words are meant to be treated as they are in Bavaria and see if the use
is informal or say adhering to the rules for submitting in APA format or
whatever. We are talking about an extremely hard problem that will still
likely make mistakes if I am from Bavaria but submitting a science fiction
article mimicking what I imagine might be the way it will be written in
3010.

So I suggest we take the source for the title function and rename it
something enlightening like changeCaseRandomMethod42dInitialUpperElseLower()
so it can be used mysteriously by anyone that wants. Then deprecate the use
of title() while keeping that as some form of alias for the fantastic new
name. Anyone wishing to have title mean anything else, feel free to redefine
it.

But that jokingly does not mean there is no room for improvement. As an
example, people often would like words like "FBI" to be left alone and not
changed to "Fbi" or in some other contexts, not be flagged as a spelling
error let alone corrected. I suspect the same or relate functions might
accept an optional arguments like maintainAllCAPS=TRUE so FBI is left alone,
albeit LOTUS123 might become Lotus123 or not.

I have seen setups where a programmer makes every imaginable function they
can think of but at some later point, some profiling of actual usage shows
that 80% of them are NEVER used. Often, that is because nobody reads all the
documentation to find out if it even exists or there is a simple workaround.
If the only thing bothering you is that a small list of words like FBI comes
out wrong, it is simple enough to write a function that post-processes the
result of title() and changes those words back.

If you designed a brand new language core today, you may indeed want to
leave title() out of the core but include it as an optional module, perhaps
with a more descriptive name.

Tell me if the base should have functions called camelCase(), PascalCase(),
arrayHungarianCase() or underscore_case() 


-Original Message-
From: Python-list  On
Behalf Of Christian Gollwitzer
Sent: Monday, March 22, 2021 4:21 PM
To: python-list@python.org
Subject: Re: .title() - annoying mistake

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 misunderstood the "here".

(native German as well, but I think it means "for keeping .title() up to
date)

I agree with Chris that .title() can be useful for "title-casing" a single
character, whatever that means. It should be documented, though, that it is
not suitable to title-case a string, not even in English.

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

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> 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_process.wait()
>
> If the process class terminates the process in __del__ (PyQt5's QProcess 
> does), then implicitly deleting process_objects after the second line will 
> break the code.

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.

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> 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_VALUE_REG still Py_INCREFs the to-be-returned
value. It's not like the data can get reclaimed before the caller
receives it.

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

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 better to just use some scalable, incremental
> implementation which would allow to forward-port it to a newer version,
> if it ever comes to that?

The motivation for revisiting this idea was/is largely personal. As I
indicated, I first messed around with it over 20 years ago and it's
been in the back of my mind ever since. Somehow I never lost the code
despite I'm not sure how many computers came and went and that the
code was never uploaded to any sort of distributed version control
system. I decided to pick things up again as a way to mostly keep my
head in the game after I retired. So, neither "research" nor
"production" seems to be a correct descriptor. Still, if taken to
functional completion — functional enough for performance testing and
application to more than just toy scripts — I realized pretty quickly
that I'd need help.

> Otherwise, if it's "production", who's the "customer" and how they
> "compensate" you for doing work (chasing the moving target) which is
> clearly of little interest to you and conflicts with the goal of the
> project?

Nobody is compensating me. I have no desire to try and turn it into
something I do for hire. Maybe I misunderstood your question?

> > This PEP proposes the addition of register-based instructions to the
> > existing Python virtual machine, with the intent that they eventually
> > replace the existing stack-based opcodes.
>
> Sorry, what? The purpose of register-based instructions is to just
> replace stack-based instructions? That's not what's I'd like to hear as
> the intro phrase. You probably want to replace one with the other
> because register-based ones offer some benefit, faster execution
> perhaps? That's what I'd like to hear instead of "deciphering" that
> between the lines.

Replacing stack-based instructions would be a reasonable initial goal,
I think. Victor reported performance improvements in his
implementation (also a translator). As I indicated in the "PEP" (I use
that term rather loosely, as I have no plans at the moment to submit
it for consideration, certainly not in its current, incomplete state),
a better ultimate way to go would be to generate register instructions
directly from the AST. The current translation scheme allows me to
write simple test case functions, generate register instructions, then
compare that when called the two produce the same result.

> > They [2 instruction sets] are almost completely distinct.
>
> That doesn't correspond to the mental image I would have. In my list,
> the 2 sets would be exactly the same, except that stack-based encode
> argument locations implicitly, while register-based - explicitly. Would
> be interesting to read (in the following "pep" sections) what makes them
> "almost completely distinct".

Well, sure. The main difference is the way two pairs of instructions
(say, BINARY_ADD vs BINARY_ADD_REG) get their operands and save their
result. You still have to be able to add two objects, call functions,
etc.

> > Within a single function only one set of opcodes or the other will
> > be used at any one time.
>
> That would be the opposite of "scalable, incremental" development
> approach mentioned above. Why not allow 2 sets to freely co-exist, and
> migrate codegeneration/implement code translation gradually?

The fact that I treat the current frame's stack space as registers
makes it pretty much impossible to execute both stack and register
instructions within the same frame. Victor's implementation did things
differently in this regard. I believe he just allocated extra space
for 256 registers at the end of each frame, so (in theory, I suppose),
you could have instructions from both executed in the same frame.

> > ## Motivation
>
> I'm not sure the content of the section corresponds much to its title.
> It jumps from background survey of the different Python VM optimizations
> to (some) implementation details of register VM - leaving "motivation"
> somewhere "between the lines".
>
> > Despite all that effort, opcodes which do nothing more than move data
> > onto or off of the stack (LOAD_FAST, LOAD_GLOBAL, etc) still account
> > for nearly half of all opcodes executed.
>
> ... And - you intend to change that with a register VM? In which way and
> how? As an example, LOAD_GLOBAL isn't going anywhere - it loads a
> variable by *symbolic* name into a register.

Certainly, if you have data which isn't already on the stack, you are
going to have to move data. As the appendix shows though, a fairly
large chunk of the current virtual machine does nothing more than
manipulate the stack (LOAD_FAST, STORE_FAST, POP_TOP, etc).

> > Running Pyperformance using a development version of Python 3.9
> > showed t

Re: Pips for python2 and python3

[Tim Johnson]

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

Re: .title() - annoying mistake

[dn via Python-list]

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 language in
> a single sentence when talking to others like myself with a dynamic to
> nonsensical grammar. Try capitalizing someone's name when they insist on
> being known by a purely numerical name like ..., or just 7 of 9 or even
> !@zq. 

Further reading: "Falsehoods Programmers Believe About Names"
(https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)

...
> I have seen setups where a programmer makes every imaginable function they
> can think of but at some later point, some profiling of actual usage shows
> that 80% of them are NEVER used. Often, that is because nobody reads all the
> documentation to find out if it even exists or there is a simple workaround.
> If the only thing bothering you is that a small list of words like FBI comes
> out wrong, it is simple enough to write a function that post-processes the
> result of title() and changes those words back.

Pareto principle ~ 80:20 rule, or should that be written "80/20 rule" or
maybe "80/20 Rule"...


Python gives you the choice to use (or not use) many facilities. You may
also choose to rename such facilities, or to re-use Python's own names
to customise functionality. You have complete freedom to use Python in
any way(s) you see fit. Thus:-

Freedom
noun
UK  /ˈfriː.dəm/ US  /ˈfriː.dəm/
 the condition or right of being able or allowed to do, say, think, etc.
whatever you want to, without being controlled or limited:
Cambridge Dictionary

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

Re: .title() - annoying mistake

[Richard Damon]

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 conection you helped me with, would you mind having a look?
>
> You misunderstood the "here".
>
> (native German as well, but I think it means "for keeping .title() up
> to date)
>
> I agree with Chris that .title() can be useful for "title-casing" a
> single character, whatever that means. It should be documented,
> though, that it is not suitable to title-case a string, not even in
> English.
>
> Christian

Part of the difficulty in getting clear documentation for this is that
is it IS somewhat complicated. You title-case a string by Title-casing
the first character of each word (and the primary issue error that
started this was the definition of a 'word'), and lower casing the rest
of the word. The complication comes in that title-casing a character
99.99% of the time doesn't give you a character in title-case, but more
often in upper-case (or uncased). There are apparently only 31 actual
characters that are 'Title-Case'. Thus the action of 'title-casing' a
character is a bit strange to describe, especially to people used to
simple languages which don't have any of the characters that cause the
issue.

We don't seem to have a problme that upper doesn't always return a true
'upper-case', like for '1' because we realize that many character don't
have case, so it gets largly just assumed we know that. For title case,
the fact that almost all characters do NOT have a 'title-case' form
makes things a bit more awkward.

Yes, perhaps the documentation could be made a bit more clear. I do note
that the documentation for str.capitalize() does talk about using actual
title case characters if the first character is a digraph. Something
like that might make sense in the description of str.title()

Note, that str.istitle() doesn't actually check if the character is a
real 'title case' character, but that the string follows a rule similar
to what str.title() produces. I am not positive that its description
exactly matches what .title() produces, but it close, and the way it is
written, "Python's".istitle() is False, as the s at the end needs to be
uppper case to satisfy as ' is uncased, so the next cased character must
be upper case.

-- 
Richard Damon

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

Re: .title() - annoying mistake

[Gene Heskett]

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 having trouble with sending log
> >> messages over
> >> the socket conection you helped me with, would you mind having a
> >> look?
> >
> > You misunderstood the "here".
> >
> > (native German as well, but I think it means "for keeping .title()
> > up to date)
> >
> > I agree with Chris that .title() can be useful for "title-casing" a
> > single character, whatever that means. It should be documented,
> > though, that it is not suitable to title-case a string, not even in
> > English.
> >
> > Christian
>
> Part of the difficulty in getting clear documentation for this is that
> is it IS somewhat complicated. You title-case a string by Title-casing
> the first character of each word (and the primary issue error that
> started this was the definition of a 'word'), and lower casing the
> rest of the word. The complication comes in that title-casing a
> character 99.99% of the time doesn't give you a character in
> title-case, but more often in upper-case (or uncased). There are
> apparently only 31 actual characters that are 'Title-Case'. Thus the
> action of 'title-casing' a character is a bit strange to describe,
> especially to people used to simple languages which don't have any of
> the characters that cause the issue.
>
> We don't seem to have a problme that upper doesn't always return a
> true 'upper-case', like for '1' because we realize that many character
> don't have case, so it gets largly just assumed we know that. For
> title case, the fact that almost all characters do NOT have a
> 'title-case' form makes things a bit more awkward.
>
> Yes, perhaps the documentation could be made a bit more clear. I do
> note that the documentation for str.capitalize() does talk about using
> actual title case characters if the first character is a digraph.
> Something like that might make sense in the description of str.title()
>
> Note, that str.istitle() doesn't actually check if the character is a
> real 'title case' character, but that the string follows a rule
> similar to what str.title() produces. I am not positive that its
> description exactly matches what .title() produces, but it close, and
> the way it is written, "Python's".istitle() is False, as the s at the
> end needs to be uppper case to satisfy as ' is uncased, so the next
> cased character must be upper case.
>
> --
> Richard Damon

I am as tired of this thread as anybody here. To me, it must be capable 
to subbing a considerably more caligraphic attention getting font and  a 
bit larger in order for it to be worth its space on the drive. We can do 
that in openoffice and its ilk with a bit of bother, but it can be done.  
Learning how to use this just adds more bother because you can do it by 
hand quicker than looking up the man page for this. OTOH, in the average 
title, that should be restricted to the first character only.

However, we've beat this horse to death, so it is not going to rear up 
and win the next Derby. So dig a hole and bury it please.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list