Re: [Python-ideas] Add Unicode-aware str.reverse() function?

[Paddy3118]

On Sunday, 9 September 2018 06:30:19 UTC+1, Steven D'Aprano wrote:
>
> On Sat, Sep 08, 2018 at 04:33:07AM -0700, Paddy3118 wrote: 
> > I wrote a blog post 
> > <
> http://paddy3118.blogspot.com/2009/07/case-of-disappearing-over-bar.html>nearly
>  
>
> > a decade ago on extending a Rosetta Code task example 
> > <http://rosettacode.org/wiki/Reverse_a_string>to handle the correct 
> > reversal of strings with combining characters. 
>
> I wouldn't care too much about a dedicated "reverse" method that handled 
> combining characters. I think that's just a special case of iterating 
> over graphemes. If we can iterate over graphemes, then reversing because 
> trivial: 
>
> ''.join(reversed(mystring.graphemes())) 
>
> The Unicode Consortium offer an algorithm for identifying grapheme 
> clusters in text strings, and there's at least three requests on the 
> tracker (one closed, two open). 
>
> https://bugs.python.org/issue30717 
>
> https://bugs.python.org/issue18406 
>  
> https://bugs.python.org/issue12733 
>

Well that ends this idea!

Thanks Steve :-)

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

[Paddy3118]

Please involve those with more knowledge on the subject. Thanks.

On Saturday, 8 September 2018 13:13:05 UTC+1, Jonathan Fine wrote:
>
> Paddy wrote
>
> > I would like to propose that Python add a Unicode-aware str.reverse 
> method.
> > The problem is, I'm a Brit, who only speaks English and only very rarely
> > dips into Unicode. I don't know how useful this would be!
>
> Excellent post and piece of work. Well done!
>
> Here's someone who might know not only how useful, but also the
> wrinkles in doing it correctly:
> 
> https://www.telecom-bretagne.eu/studies/msc/professors/haralambous/
>
> Yannis Haralambous received his Ph.D. in Pure Mathematics from the
> Université de Sciences et Techniques de Lille-Flandre-Artois, Lille,
> France in 1990. He is currently working as a full-time Professor at
> Institut Mines-Telecom/Telecom Bretagne, Brest, in the Computer
> Science Department. His research areas include digital typography and
> representation of text, electronic documents, internationalization of
> documents, character encodings and the preservation of the cultural
> heritage of the book in the digital era. He is the author of Fonts &
> Encodings, to be published by O'Reilly in 2007 (French version :
> Fontes & codages, O'Reilly France, 2003).
> 
>
> I know Yannis, so could approach him on behalf of this list.
>
> --
> Jonathan
> ___
> Python-ideas mailing list
> python...@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add Unicode-aware str.reverse() function?

[Paddy3118]

Thanks for your replies.

After reading them,, although I seem to have a brain freeze at the moment 
and 
cannot think of an algorithm; I think it plausible, just in the ASCII world 
for 
someone to want to iterate through characters in a string in reverse order 
- 
maybe to zip with another existing iterable that would otherwise need to be 
reversed? If it shifted from ASCII to unicode then letters with their 
combining
characters would have to be reversed as a single character; but also 
iterated 
over as a single unicode "character" - another problem!

I thought so, I scratch the surface of unicode, and find a deep chasm 
awaits.

On Saturday, 8 September 2018 12:33:07 UTC+1, Paddy3118 wrote:
>
> I wrote a blog post 
> <http://paddy3118.blogspot.com/2009/07/case-of-disappearing-over-bar.html>nearly
>  
> a decade ago on extending a Rosetta Code task example 
> <http://rosettacode.org/wiki/Reverse_a_string>to handle the correct 
> reversal of strings with combining characters.
> On checking my blog statistics today I found that it still had a 
> readership and revisited the code 
> <http://rosettacode.org/wiki/Reverse_a_string#Python:_Unicode_reversal> 
> (and updated it to Python3.6)..
>
> I found that amongst the nearly 200 languages that complete the RC 
> task,there were a smattering of languages that correctly handled reversing 
> strings having Unicode combining characters,
> including Perl 6 <http://rosettacode.org/wiki/Reverse_a_string#Perl_6> 
> which uses flip.
>
> I would like to propose that Python add a Unicode-aware *str.reverse *method. 
> The problem is, I'm a Brit, who only speaks English and only very rarely 
> dips into Unicode.* I don't know how useful this would be!*
>
> Cheers, Paddy.
>
>
>
>___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add Unicode-aware str.reverse() function?

[Paddy3118]

I wrote a blog post 
<http://paddy3118.blogspot.com/2009/07/case-of-disappearing-over-bar.html>nearly
 
a decade ago on extending a Rosetta Code task example 
<http://rosettacode.org/wiki/Reverse_a_string>to handle the correct 
reversal of strings with combining characters.
On checking my blog statistics today I found that it still had a readership 
and revisited the code 
<http://rosettacode.org/wiki/Reverse_a_string#Python:_Unicode_reversal> 
(and updated it to Python3.6)..

I found that amongst the nearly 200 languages that complete the RC 
task,there were a smattering of languages that correctly handled reversing 
strings having Unicode combining characters,
including Perl 6 <http://rosettacode.org/wiki/Reverse_a_string#Perl_6> 
which uses flip.

I would like to propose that Python add a Unicode-aware *str.reverse *method. 
The problem is, I'm a Brit, who only speaks English and only very rarely 
dips into Unicode.* I don't know how useful this would be!*

Cheers, Paddy.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Remember the Vasa

[Paddy3118]

I thought it might be helpful for the Python community to be aware of the 
growth issues that the C++ community has/is discussing, at the moment. I am 
*not 
*saying we have those same issues, but we might know to avoid similar 
issues in our future?

Here's and letter:
  http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf

And an article on a later interview:
  http://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hmm, yea I had not thought of how it would look - I had thought formost of 
not needing to necessarily learn about bitsets.when learning about passing 
a large number of optional flags to a function.

Although the default could be None, interpreted as an empty set of zero 
values.; a set of one or more enums does use more characters compared to 
or-ing flags...

On Sunday, 31 December 2017 05:34:23 UTC, Guido van Rossum wrote:
>
> On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee  > wrote:
>>
>> Paddy might want something like this:
>> - For existing APIs which take int or IntFlag flags, allow them to
>> also take a set (or perhaps any collection) of flags.
>> - In new APIs, take sets of Enum flags, and don't make them IntFlag.
>> - Documentation should show preference toward using sets of Enum
>> flags. Tutorials should pass sets.
>
>
> I'm not keen on this recommendation. An argument that takes a Set[Foo] 
> would mean that in order to specify:
> - no flags: you'd have to pass set() -- you can't use {} since that's an 
> empty dict, not an empty set
> - one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
> - two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR | 
> Foo.BAZ
>
> I think for each of these the proposal would be strictly worse than the 
> current convention.
>
> -- 
> --Guido van Rossum (python.org/~guido)
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hi Inada, can I take your point as being that execution speed is an issue? 

I am coming from the "Python as higher level, more programmer-centric 
language"direction.

In the past, useful but slow things have spurred actions to speed them up. ___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hi Steve, I did not write an attack on the "Python devs". Re-read my 
original with a little less hostility and there should be room for an 
interpretation, (which I meant), that does not warrant such a hostile reply.

The original is written in the hope of furthering discussion on the need 
for what is deemed pythonic , and on what Python is taught , as the 
language itself changes.
We now have enums if you want to pass a set of flags to a function then you 
could have them as separate arguments - but that leads to long and 
cumbersome parameter lists; you could, and many do, have flags that are 
individual powers of two and then or them together and pass the result - 
creating a bitset; but we can now have the flags as separate enum.Enums and 
pass a set of values to a function as the flag set. 

This new way means that people being taught the method can use a knowledge 
of sets and enums - no need to know about powers of two,, what happens when 
they are bit-or'd together; and bitsets. We have gone to a higher level 
description of what we are doing; no need to mired in the details of the 
how of what one wants to achieve. bitsets can be taught as an optimisation.

As for re, and otheralready written libraries, their is no need to change 
them, but other Pythoneers might well opt to not use bitsets, but rather 
sets of enum values.


On Wednesday, 27 December 2017 05:58:00 UTC, Steven D'Aprano wrote:
>
> On Tue, Dec 26, 2017 at 12:07:52PM -0800, Paddy3118 wrote: 
>
> > Maybe it is time to deemphasize the creation and passing of what is, in 
> > effect, bit-sets <https://en.wikipedia.org/wiki/Bit_array>as a single 
> > argument, and instead promote the passing of a set of members of an 
> > enum.Enum <https://docs.python.org/3/library/enum.html> constants. 
>
> That implies that we are promoting bit sets (not merely using them). 
> Where are we doing that? 
>
>
> > Thi comes about because someone wrote a description, (since deleted), 
>
> "Someone"? One of the Python core developers? 
>
> If not, well, the Python devs cannot be held responsible for what random 
> people on the internet write. 
>
>
> > of 
> > constructing bit-sets to use in passing flags to, for example, the 
> > re.compile <https://docs.python.org/3/library/re.html#re.compile>function. 
>
> > The use of individual bits in a bit-array/bit-set to pass multiple flags 
> is 
> > an implementation detail. 
>
> It certainly is not an implementation detail -- it is a part of the 
> public, published interface to the re module. 
>
> Of course had history been different, re.compile *could* have taken a 
> set of Enums instead. But that doesn't make it an implementation detail. 
> That would be like saying that: 
>
>re.search(pattern, text, flags=0) 
>
> is an implementation detail, and we should feel free to change it to 
>
>re.examine(text, pattern, set_of_enums=frozenset()) 
>
> We can't change a public interface documented as taking an integer to 
> one taking a set of Enums without going through a deprecation period. 
>
> However, we could *add* an additional interface, where the re functions 
> that currently accept an integer flag *also* accepts a set of Enums. 
>
>
> > Should we not *first *teach the passing of a set 
> > of enum.Enum constant values in one argument as the *pythonic *way; 
>
> What makes you say that is the Pythonic way? (That's not a rhetorical 
> question.) 
>
>
> -- 
> Steve 
> ___ 
> Python-ideas mailing list 
> python...@python.org  
> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Maybe it is time to deemphasize the creation and passing of what is, in 
effect, bit-sets as a single 
argument, and instead promote the passing of a set of members of an 
enum.Enum  constants.

Thi comes about because someone wrote a description, (since deleted), of 
constructing bit-sets to use in passing flags to, for example, the 
re.compile function. 
The use of individual bits in a bit-array/bit-set to pass multiple flags is 
an implementation detail. Should we not *first *teach the passing of a set 
of enum.Enum constant values in one argument as the *pythonic *way; and 
leave bit-sets and other types of enum's as a performance or 
interoperability detail?

Comments please, (And a happy new year to you :-)

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/