"monty" < "python"

[Dave Angel]

I don't think Mickey Mouse knew about that call, otherwise he'd have
used it. Either that, or he had a completely saturated system and
couldn't type anything at the console, so it took the wizard's SSH
session to deal with the problem using "kill -9".

Denial-of-service, the traditional way.

 

[istjanichtzufassen]

Am Donnerstag, 21. März 2013 10:36:20 UTC+1 schrieb David H Wild:

Similarly, the snake was a nadder - congruent with the natterjack toad.

And conversely, the "nickname" once was "an ekename", meaning an additionalname.

 

[Chris Angelico]

Am Donnerstag, 21. März 2013 10:36:20 UTC+1 schrieb David H Wild:

And conversely, the "nickname" once was "an ekename", meaning an additional name.

Until Eccles came along. Most people call him by his nickname, which is "Nick".

ChrisA

 

[Grant Edwards]

By the way, the "n" in "an" is not the only such "bridging" sound. In
Shakespearean times, it was usual to use "mine" in the same fashion:

In many (most?) modern, non-rhotic, dialects of English one inserts an
"intrusive" bridging "R" sound after a word that ends in certain vowel
sounds and is followed by a word starting with a vowel.

That description is a bit hard to "picture", but if you read the
examples in the link below, you'll recogize it immediately:

http://en.wikipedia.org/wiki/Linking_and_intrusive_R#Linking_R

However, this only affects spoken English -- not written English.

Is the Python language rhotic or non-rhotic?

 

[Peter Pearson]

Hey look, snakes, we're back on topic!

Ha! Great shot, Chris A.

People who enjoy this sort of linguistic diversion would
very likely enjoy John McWhorter's classes from the Teaching
Company, which is where I first encountered many of the examples
given in this thread.

 

[Chris Angelico]

Ha! Great shot, Chris A.

People who enjoy this sort of linguistic diversion would
very likely enjoy John McWhorter's classes from the Teaching
Company, which is where I first encountered many of the examples
given in this thread.

I love a good grammar discussion. Programming requires precise use of
some language, so programmers tend to appreciate precise use of other
languages too. Plus, in one of my other lives, I'm a D&D Dungeon
Master with a reputation for puns and wordplay in my descriptions...
though I'm as often slapped as clapped for them.

ChrisA

 

[Terry Reedy]

On 3/21/2013 1:31 PM, Grant Edwards wrote:


http://en.wikipedia.org/wiki/Linking_and_intrusive_R

Is the Python language rhotic or non-rhotic?

Python uses American rather that British English, which would make it
rhotic.

I never imagined that there were people who would mix up 'tuner' and
'tuna'. Live and learn.

 

[Roy Smith]

On 3/21/2013 1:31 PM, Grant Edwards wrote:


http://en.wikipedia.org/wiki/Linking_and_intrusive_R


Python uses American rather that British English, which would make it
rhotic.

I never imagined that there were people who would mix up 'tuner' and
'tuna'. Live and learn.

Remember, "You can tune a file system, but you can't tune a fish."

 

[Grant Edwards]

On 3/21/2013 1:31 PM, Grant Edwards wrote:

http://en.wikipedia.org/wiki/Linking_and_intrusive_R


Python uses American rather that British English, which would make it
rhotic.

Well, there are parts of New England, New York and the Southeast that
have historically been non-rhotic.

 

[jmfauth]

Now lets take this piece by piece…
"I did an horrible mistake" : I am sorry. Did you get bruised? Break
some bones? And is 'h' a vowel in french?
"I forgot Py33 is now optimized for ascii user"  Ok.
"it is no more unicode compliant" I asked earlier and I ask again --
What do you mean by (non)compliant?

------

One aspect of Unicode (note the capitalized "U").

py32

timeit.repeat("'abc需'.find('a')") [0.27941279564856814, 0.26568106110789813, 0.265546366757917]
timeit.repeat("'abcdef'.find('a')")

[0.2891812867801491, 0.26698153112010914, 0.26738994644529157]

py33
timeit.repeat("'abc需'.find('a')")
[0.5941777382531654, 0.5829193385634426, 0.5519412133990045]
timeit.repeat("'abcdef'.find('a')")
[0.44333188136533863, 0.4232506078969891, 0.4225164843046514]


---

In French, depending of the word, a leading "h", behaves
as a vowel or as a consonant.
(From this -> this typical mistake)

jmf

 

[jmfauth]

It has been acknowledged as a real regression, but he keeps hijacking every
thread where strings are mentioned to harp on about it. He has shown no
inclination to attempt to *fix* the regression and is rapidly coming to be
regarded as a troll by most participants in this list.

---------

I can not help to fix it, because it is "unfixable". It
is "unfixable", because this flexible string representation
is wrong by design.

jmf

 

[Chris Angelico]

One aspect of Unicode (note the capitalized "U").

[chomp yet another trivial microbenchmark]

---

In French, depending of the word, a leading "h", behaves
as a vowel or as a consonant.
(From this -> this typical mistake)

Huh? Did jmf and 88888 Dihedral just team up to make a post?

ChrisA

 

[Chris Angelico]

One aspect of Unicode (note the capitalized "U").

[chomp yet another trivial microbenchmark]

---

In French, depending of the word, a leading "h", behaves
as a vowel or as a consonant.
(From this -> this typical mistake)

Huh? Did jmf and 88888 Dihedral just team up to make a post?

Ohh. That's in relation to "an horrible mistake". Though I still don't
see what the parenthesis is saying.

Pity, that. A merger between jmf and Dihedral would have been mutually
beneficial. I'm sure it would be approved by the regulatory
authorities, too.

ChrisA

 

[Mark Lawrence]

Now lets take this piece by piece…
"I did an horrible mistake" : I am sorry. Did you get bruised? Break
some bones? And is 'h' a vowel in french?
"I forgot Py33 is now optimized for ascii user" Ok.
"it is no more unicode compliant" I asked earlier and I ask again --
What do you mean by (non)compliant?

------

One aspect of Unicode (note the capitalized "U").

py32

timeit.repeat("'abc需'.find('a')") [0.27941279564856814, 0.26568106110789813, 0.265546366757917]
timeit.repeat("'abcdef'.find('a')")

[0.2891812867801491, 0.26698153112010914, 0.26738994644529157]

py33
timeit.repeat("'abc需'.find('a')")
[0.5941777382531654, 0.5829193385634426, 0.5519412133990045]
timeit.repeat("'abcdef'.find('a')")
[0.44333188136533863, 0.4232506078969891, 0.4225164843046514]

jmf

Are you saying that to be compliant a unicode implementation has to
perform within given time bounds?

 

[Mark Lawrence]

---------

I can not help to fix it, because it is "unfixable". It
is "unfixable", because this flexible string representation
is wrong by design.

jmf

Of course it's fixable. All you need do is write a PEP clearing stating
what is wrong with the implementation detailed in PEP393 and your own
proposed design. I'm looking forward to reading this PEP.

Note that going backwards to buggier unicode implementations that
existed in Python prior to version 3.3 is simply not an option.

 

[jmfauth]

----
[snip usual rant from jmf]
It has been acknowledged as a real regression, but he keeps hijacking every
thread where strings are mentioned to harp on about it. He has shown no
inclination to attempt to *fix* the regression and is rapidly coming to be
regarded as a troll by most participants in this list.

---------

I can not help to fix it, because it is "unfixable". It
is "unfixable", because this flexible string representation
is wrong by design.

jmf

Of course it's fixable.  All you need do is write a PEP clearing stating
what is wrong with the implementation detailed in PEP393 and your own
proposed design.  I'm looking forward to reading this PEP.

Note that going backwards to buggier unicode implementations that
existed in Python prior to version 3.3 is simply not an option.

------

The problem here is that this PEP 393 should not have been
created.
The first time I read it, I quickly understood, it can
not work!

This is illustrated by all the examples I give on this list.
In all the cases, I can explain why.

I never saw somebody beeing able to argue these examples are
wrong and/or explaining why they are wrong, except arguing
the flexible string representation exists!

jmf

 

[Chris Angelico]

The problem here is that this PEP 393 should not have been
created.
The first time I read it, I quickly understood, it can
not work!

I fail to understand how something can "not work" when it is clearly
working, and very successfully too, in two different languages. All of
your complaints have been on the basis of *timings*, which really
means you're complaining about performance, not correctness. If you
can show any evidence that something actually is not *working*, please
do so (in a fresh thread, not in a hijacked one).

ChrisA

 

[Mark Lawrence]

The problem here is that this PEP 393 should not have been
created.
The first time I read it, I quickly understood, it can
not work!

How come you couldn't pursuade the Python devs that PEP393 was so flawed?

This is illustrated by all the examples I give on this list.
In all the cases, I can explain why.

IIRC you've never said that the implementation doesn't work. You've
repeatedly given micro benchmarks regarding performance and nothing else.

I never saw somebody beeing able to argue these examples are
wrong and/or explaining why they are wrong, except arguing
the flexible string representation exists!

Sheer unadultered crap. Was your education at the Dr Goebbels Institute?

 

[Stefan Behnel]

Terry Reedy, 22.03.2013 00:05:

I never imagined that there were people who would mix up 'tuner' and
'tuna'. Live and learn.

I assume you know "The Chaos" ?

http://ncf.idallen.com/english.html

Stefan

 

[rusi]

I assume you know "The Chaos" ?

http://ncf.idallen.com/english.html

Ha! Sweet! (Or should I say suet?)