Re: .title() - annoying mistake
The real reason Python strings support a .title() method is surely because Unicode supports upper, lower, _and_ title case letters, and tells you how to map between them. Consider: >>> '\u01f1'.upper() '\u01f1' This is the "DZ" character. >>> '\u01f1'.lower() '\u01f3' This is the "dz" character. >>> '\u01f1'.title() '\u01f2' This is the "Dz" character. When you write that code to capitalize your book titles, you should be calling .title() rather than .upper() if you are doing it right. -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On Sat, Mar 20, 2021 at 04:34:02AM -0400, Alan Bawden wrote: > The real reason Python strings support a .title() method is surely > because Unicode supports upper, lower, _and_ title case letters, and > tells you how to map between them. Consider: > >>>> '\u01f1'.upper() >'\u01f1' > > This is the "DZ" character. > >>>> '\u01f1'.lower() >'\u01f3' > > This is the "dz" character. > >>>> '\u01f1'.title() >'\u01f2' > > This is the "Dz" character. > > When you write that code to capitalize your book titles, you should be > calling .title() rather than .upper() if you are doing it right. It would be great to read this reasoning in the documentation. Cheers, David -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
Am 20.03.2021 um 09:34 schrieb Alan Bawden: The real reason Python strings support a .title() method is surely because Unicode supports upper, lower, _and_ title case letters, and tells you how to map between them. Consider: >>> '\u01f1'.upper() '\u01f1' This is the "DZ" character. >>> '\u01f1'.lower() '\u01f3' This is the "dz" character. >>> '\u01f1'.title() '\u01f2' This is the "Dz" character. When you write that code to capitalize your book titles, you should be calling .title() rather than .upper() if you are doing it right. But that's exactly what he's doing, with a result which is documented, but not really satisfactory. -- https://mail.python.org/mailman/listinfo/python-list
Looking for people interested in a Python register virtual machine project
Back in the late 90s (!) I worked on a reimagining of the Python virtual machine as a register-based VM based on 1.5.2. I got part of the way with that, but never completed it. In the early 2010s, Victor Stinner got much further using 3.4 as a base. The idea (and dormant code) has been laying around in my mind (and computers) these past couple decades, so I took another swing at it starting in late 2019 after retirement, mostly as a way to keep my head in the game. While I got a fair bit of the way, it stalled. I've picked it up and put it down a number of times in the past year, often needing to resolve conflicts because of churn in the current Python virtual machine. Though I kept getting things back in sync, I realize this is not a one-person project, at least not this one person. There are several huge chunks of Python I've ignored over the past 20 years, and not just the internals. (I've never used async anything, for example.) If it is ever to truly be a viable demonstration of the concept, I will need help. I forked the CPython repo and have a branch (register2) of said fork which is currently synced up with the 3.10 (currently master) branch: https://github.com/smontanaro/cpython/tree/register2 I started on what could only very generously be called a PEP which you can read here. It includes some of the history of this work as well as details about what I've managed to do so far: https://github.com/smontanaro/cpython/blob/register2/pep-.rst If you think any of this is remotely interesting (whether or not you think you'd like to help), please have a look at the "PEP". Because this covers a fair bit of the CPython implementation, chances to contribute in a number of areas exist, even if you have never delved into Python's internals. Questions/comments/pull requests welcome. Skip Montanaro -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Looking for people interested in a Python register virtual machine project
Yes, I remember Parrot. As I understand it their original goal was a language-agnostic virtual machine, which might have complicated things. I will do a bit of reading and add some text to the "PEP." Skip On Sat, Mar 20, 2021, 11:36 AM David Mertz wrote: > The Parrot project was also intended to be the same thing, and for a while > had a fair number of contributors. Unfortunately, it never obtained the > performance wins that were good for. > > On Sat, Mar 20, 2021, 11:55 AM Skip Montanaro > wrote: > >> Back in the late 90s (!) I worked on a reimagining of the Python >> virtual machine as a register-based VM based on 1.5.2. I got part of >> the way with that, but never completed it. In the early 2010s, Victor >> Stinner got much further using 3.4 as a base. The idea (and dormant >> code) has been laying around in my mind (and computers) these past >> couple decades, so I took another swing at it starting in late 2019 >> after retirement, mostly as a way to keep my head in the game. While I >> got a fair bit of the way, it stalled. I've picked it up and put it >> down a number of times in the past year, often needing to resolve >> conflicts because of churn in the current Python virtual machine. >> Though I kept getting things back in sync, I realize this is not a >> one-person project, at least not this one person. There are several >> huge chunks of Python I've ignored over the past 20 years, and not >> just the internals. (I've never used async anything, for example.) If >> it is ever to truly be a viable demonstration of the concept, I will >> need help. I forked the CPython repo and have a branch (register2) of >> said fork which is currently synced up with the 3.10 (currently >> master) branch: >> >> https://github.com/smontanaro/cpython/tree/register2 >> >> I started on what could only very generously be called a PEP which you >> can read here. It includes some of the history of this work as well as >> details about what I've managed to do so far: >> >> https://github.com/smontanaro/cpython/blob/register2/pep-.rst >> >> If you think any of this is remotely interesting (whether or not you >> think you'd like to help), please have a look at the "PEP". Because >> this covers a fair bit of the CPython implementation, chances to >> contribute in a number of areas exist, even if you have never delved >> into Python's internals. Questions/comments/pull requests welcome. >> >> Skip Montanaro >> ___ >> Python-ideas mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/[email protected]/message/IUKZPH4ZSZ22RZFKMITQ3Q6A22P4BXWX/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
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. robert -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On Sun, Mar 21, 2021 at 4:31 AM 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. > The problem is that you haven't read the documentation :) It very carefully does NOT define itself by language, and its behaviour is identical regardless of the language used. Notably, it doesn't care what script you're using, and will happily upper/lowercase letters in a variety of different scripts, even in a single string. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
Sibylle Koczian writes: Am 20.03.2021 um 09:34 schrieb Alan Bawden: > > When you write that code to capitalize your book titles, you should be > calling .title() rather than .upper() if you are doing it right. > But that's exactly what he's doing, with a result which is documented, but not really satisfactory. Sorry, what I wrote was ambiguous. What I _meant_ was that when you replace x.title() with my_title(x) , then in the definition of my_title you will be calling both .lower() and .title() on individual characters, but you will probably _never_ be calling .upper(). -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 20Mar2021 12:53, Sibylle Koczian wrote: >Am 20.03.2021 um 09:34 schrieb Alan Bawden: >>The real reason Python strings support a .title() method is surely >>because Unicode supports upper, lower, _and_ title case letters, and >>tells you how to map between them. [...] >> >But that's exactly what he's doing, with a result which is documented, >but not really satisfactory. Not to mention that the .title method _predates_ Python's use of Unicode in strings. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 2021-03-20, Cameron Simpson wrote: > On 20Mar2021 12:53, Sibylle Koczian wrote: >>Am 20.03.2021 um 09:34 schrieb Alan Bawden: >>>The real reason Python strings support a .title() method is surely >>>because Unicode supports upper, lower, _and_ title case letters, and >>>tells you how to map between them. [...] >>> >>But that's exactly what he's doing, with a result which is documented, >>but not really satisfactory. > > Not to mention that the .title method _predates_ Python's use of Unicode > in strings. Well, it predates Python's use of Unicode in the default string type, but not Python's use of Unicode in strings. https://github.com/python/cpython/commit/4c08d554b9009899780a5e003d6bbeb5413906ee -- https://mail.python.org/mailman/listinfo/python-list
Re: .title() - annoying mistake
On 20Mar2021 23:18, Jon Ribbens wrote: >On 2021-03-20, Cameron Simpson wrote: >> Not to mention that the .title method _predates_ Python's use of >> Unicode >> in strings. > >Well, it predates Python's use of Unicode in the default string type, >but not Python's use of Unicode in strings. > >https://github.com/python/cpython/commit/4c08d554b9009899780a5e003d6bbeb5413906ee Thank you for this correction. Cheers, Cameron -- https://mail.python.org/mailman/listinfo/python-list
