Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #19315 > unrolled thread

The devolution of English language and slothful c.l.p behaviors exposed!

Back to article view | Back to comp.lang.python

Contents

  The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-23 21:57 -0800
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-24 06:06 +0000
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Benedict Verheyen <benedict.verheyen@gmail.com> - 2012-01-24 16:43 +0100
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Evan Driscoll <edriscoll@wisc.edu> - 2012-01-24 00:05 -0600
      Re: The devolution of English language and slothful c.l.p behaviors exposed! alex23 <wuwei23@gmail.com> - 2012-01-23 22:50 -0800
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Chris Angelico <rosuav@gmail.com> - 2012-01-24 17:41 +1100
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Grant Edwards <invalid@invalid.invalid> - 2012-01-24 13:46 +0000
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Andrew Berg <bahamutzero8825@gmail.com> - 2012-01-24 00:49 -0600
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-23 23:53 -0700
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Chris Angelico <rosuav@gmail.com> - 2012-01-24 17:59 +1100
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Jérôme <jerome@jolimont.fr> - 2012-01-24 09:21 +0100
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-24 16:25 +0000
    Re: The devolution of English language and slothful c.l.p behaviors exposed! "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-01-24 14:05 +0000
      RE: The devolution of English language and slothful c.l.p behaviors exposed! Rob Richardson <RDRichardson@rad-con.com> - 2012-01-24 14:54 +0000
      Re: The devolution of English language and slothful c.l.p behaviors exposed! J <dreadpiratejeff@gmail.com> - 2012-01-24 09:51 -0500
        Re: The devolution of English language and slothful c.l.p behaviors exposed! "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-01-24 16:26 +0000
          Re: The devolution of English language and slothful c.l.p behaviors exposed! Chris Angelico <rosuav@gmail.com> - 2012-01-25 03:41 +1100
          Re: The devolution of English language and slothful c.l.p behaviors exposed! Blockheads Oi Oi <breamoreboy@yahoo.co.uk> - 2012-01-24 17:21 +0000
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-01-25 00:01 -0500
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Andrea Crotti <andrea.crotti.0@gmail.com> - 2012-01-24 15:46 +0000
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Blockheads Oi Oi <breamoreboy@yahoo.co.uk> - 2012-01-24 17:25 +0000
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Blockheads Oi Oi <breamoreboy@yahoo.co.uk> - 2012-01-24 21:13 +0000
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Chris Angelico <rosuav@gmail.com> - 2012-01-25 08:20 +1100
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Blockheads Oi Oi <breamoreboy@yahoo.co.uk> - 2012-01-24 21:26 +0000
    RE: The devolution of English language and slothful c.l.p behaviours exposed! Phil Runciman <philr@aspexconsulting.co.nz> - 2012-01-25 13:32 +1300
    Re: The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-24 16:43 -0800
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Michael Torrie <torriem@gmail.com> - 2012-01-24 22:49 -0700
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Michael Torrie <torriem@gmail.com> - 2012-01-24 22:55 -0700
      Re: The devolution of English language and slothful c.l.p behaviors exposed! MRAB <python@mrabarnett.plus.com> - 2012-01-25 19:50 +0000
    Re: The devolution of English language and slothful c.l.p behaviours exposed! Blockheads Oi Oi <breamoreboy@yahoo.co.uk> - 2012-01-25 01:38 +0000
    Re: The devolution of English language and slothful c.l.p behaviors exposed! K Richard Pixley <rich@noir.com> - 2012-01-25 09:26 -0800
      Re: The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-25 12:14 -0800
        Re: The devolution of English language and slothful c.l.p behaviors exposed! Neil Cerutti <neilc@norwich.edu> - 2012-01-25 20:32 +0000
        Re: The devolution of English language and slothful c.l.p behaviors exposed! Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-25 14:45 -0700
          Re: The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-25 15:23 -0800
            Re: The devolution of English language and slothful c.l.p behaviors exposed! Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-25 17:20 -0700
              Re: The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-25 17:00 -0800
                Re: The devolution of English language and slothful c.l.p behaviors exposed! Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-25 19:02 -0700
                  Re: The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-25 19:01 -0800
                    Re: The devolution of English language and slothful c.l.p behaviors exposed! Chris Angelico <rosuav@gmail.com> - 2012-01-26 14:57 +1100
            Re: The devolution of English language and slothful c.l.p behaviors exposed! Jugurtha Hadjar <jugurtha.hadjar@gmail.com> - 2012-01-26 01:28 +0100
              Re: The devolution of English language and slothful c.l.p behaviors exposed! Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-25 17:34 -0800
            Re: The devolution of English language and slothful c.l.p behaviors exposed! John O'Hagan <research@johnohagan.com> - 2012-01-26 11:37 +1100
            Re: The devolution of English language and slothful c.l.p behaviors exposed! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-26 05:14 +0000
              Re: The devolution of English language and slothful c.l.p behaviors exposed! Chris Angelico <rosuav@gmail.com> - 2012-01-26 16:19 +1100
              Re: The devolution of English language and slothful c.l.p behaviors exposed! rusi <rustompmody@gmail.com> - 2012-01-25 21:25 -0800
                Re: The devolution of English language and slothful c.l.p behaviors exposed! Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-26 00:51 -0700
              Re: The devolution of English language and slothful c.l.p behaviors exposed! Emile van Sebille <emile@fenx.com> - 2012-01-27 09:06 -0800
                Re: The devolution of English language and slothful c.l.p behaviors exposed! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-27 19:42 +0000
        Re: The devolution of English language and slothful c.l.p behaviors exposed! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-26 00:53 +0000
          Re: The devolution of English language and slothful c.l.p behaviors exposed! alex23 <wuwei23@gmail.com> - 2012-01-26 16:31 -0800
        Re: The devolution of English language and slothful c.l.p behaviors exposed! "K. Richard Pixley" <rich@noir.com> - 2012-01-25 16:55 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#19364

On 24/01/2012 15:46, Andrea Crotti wrote:
> I suggest to create English 2.0, and convince the whole world to speak
> your own
> way better implementation of English.

Too late for that when comparing modern English with that of e.g. 
Dickens, Shakespeare, Chaucer and Bede, hence at a minimum I reckon we 
should be at 6.0.

Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#19371

On 24/01/2012 20:03, Joshua Landau wrote:
> On 24 January 2012 17:25, Blockheads Oi Oi <breamoreboy@yahoo.co.uk
> <mailto:breamoreboy@yahoo.co.uk>> wrote:
>
>     On 24/01/2012 15:46, Andrea Crotti wrote:
>
>         I suggest to create English 2.0, and convince the whole world to
>         speak
>         your own
>         way better implementation of English.
>
>
>     Too late for that when comparing modern English with that of e.g.
>     Dickens, Shakespeare, Chaucer and Bede, hence at a minimum I reckon
>     we should be at 6.0.
>
>
> A simple version number doesn't imply huge breakages. Try "English2 v1.0"!
>
> In fact, why would a perfect language need a version number?
>
>
It would be difficult to maintain Python without a version number.

[toc] | [prev] | [next] | [standalone]

#19372

On Wed, Jan 25, 2012 at 8:13 AM, Blockheads Oi Oi
<breamoreboy@yahoo.co.uk> wrote:
> On 24/01/2012 20:03, Joshua Landau wrote:
>> A simple version number doesn't imply huge breakages. Try "English2 v1.0"!
>>
>> In fact, why would a perfect language need a version number?
>>
> It would be difficult to maintain Python without a version number.

That just proves that Guido couldn't get it right, because he isn't as
perfect as Rick. No; Rick wouldn't need a version identifier, because
he would get it right the first time.

ChrisA

[toc] | [prev] | [next] | [standalone]

#19373

On 24/01/2012 21:20, Chris Angelico wrote:
> On Wed, Jan 25, 2012 at 8:13 AM, Blockheads Oi Oi
> <breamoreboy@yahoo.co.uk>  wrote:
>> On 24/01/2012 20:03, Joshua Landau wrote:
>>> A simple version number doesn't imply huge breakages. Try "English2 v1.0"!
>>>
>>> In fact, why would a perfect language need a version number?
>>>
>> It would be difficult to maintain Python without a version number.
>
> That just proves that Guido couldn't get it right, because he isn't as
> perfect as Rick. No; Rick wouldn't need a version identifier, because
> he would get it right the first time.
>
> ChrisA
No; Rick wouldn't need a version number, because he never writes 
anything that needs a version number.

Cheers.

Mark Lawrence.

p.s. please accept my apologies for not sticking my name on previous 
replies.

[toc] | [prev] | [next] | [standalone]

#19375 — RE: The devolution of English language and slothful c.l.p behaviours exposed!

"Talking" about version numbers, shouldn't the English dictionary and grammar be under version control? I nominate Oxford University to administer this, after all they produce the largest English dictionary and are experts on English grammar. Someone had better let them know because the impending avalanche of bookings out for modification may take them by surprise, especially the number of requests from the North America and Australia. 

Here in New Zealand, they gave up attempting to use correct English years ago. 


Phil Runciman 

 
> -----Original Message-----
> From: Blockheads Oi Oi [mailto:breamoreboy@yahoo.co.uk]
> Sent: Wednesday, 25 January 2012 10:26 a.m.
> To: python-list@python.org
> Subject: Re: The devolution of English language and slothful c.l.p
> behaviors exposed!
> 
> On 24/01/2012 21:20, Chris Angelico wrote:
> > On Wed, Jan 25, 2012 at 8:13 AM, Blockheads Oi Oi
> > <breamoreboy@yahoo.co.uk>  wrote:
> >> On 24/01/2012 20:03, Joshua Landau wrote:
> >>> A simple version number doesn't imply huge breakages. Try "English2
> v1.0"!
> >>>
> >>> In fact, why would a perfect language need a version number?
> >>>
> >> It would be difficult to maintain Python without a version number.
> >
> > That just proves that Guido couldn't get it right, because he isn't
> as
> > perfect as Rick. No; Rick wouldn't need a version identifier, because
> > he would get it right the first time.
> >
> > ChrisA
> No; Rick wouldn't need a version number, because he never writes
> anything that needs a version number.
> 
> Cheers.
> 
> Mark Lawrence.
> 
> p.s. please accept my apologies for not sticking my name on previous
> replies.
> 

[toc] | [prev] | [next] | [standalone]

#19376

On Jan 23, 11:57 pm, Rick Johnson <rantingrickjohn...@gmail.com>
wrote:
> Here is a grep from the month of September 2011 showing the rampantly
> egregious misuse of the following words and phrases:

Actually my custom script had a small flaw which kept it from
capturing ALL the atrocities. Here is a run with the bugfixes:

  pretty: 54
  hard: 47
  right: 117
  used to: 37
  supposed to: 18

I'm thinking of posting monthly digests for all to see so that
HOPEFULLY you folks may give some thought to your words before pecking
them out. I must admit, I wept internally after seeing this latest
digest.


------------------------------------------------------------
Found 54 unique occurances of "pretty" in a sentence:
------------------------------------------------------------

| I'm "PRETTY" sure, you problem comes from this.
|
| That's "PRETTY" good, too.
|
| I wholeheartedly support the sentiment behind your
| statement, even if i quibble slightly - your statement has
| accuracy, it merely wants precision :) i'll watch your vid
| once i'm home from work - it promises to be some "PRETTY"
| cool stuff!
|
| I think the problem many people ignore when coming up with
| solutions like this is that while this behaviour is
| "PRETTY" much unique for turkish script, there is no
| guarantee that turkish substrings won't appear in other
| language strings (or vice versa).
|
| That's "PRETTY" great too, i guess.
|
| Seems "PRETTY" logical to me.
|
| My concern about the multiprocessing module technique is
| that launching a process for every regex evaluation sounds
| "PRETTY" inefficient.
|
| I'm "PRETTY" sure it is because of my c background
| (actually i learned python before c, and thus learned %
| formatting in python).
|
| Avoiding them is "PRETTY" easy here.
|
| Plus, indentation makes it "PRETTY".
|
| "PRETTY" easy to do though.
|
| For me, they're also "PRETTY" rare; many programs i write
| have no explicit continuations in them at all.
|
| Personally, i find that to be "PRETTY" bizarre -- but it
| worked.
|
| 2011 05:42 schrieb atherun: i'm "PRETTY" sure thats the
| problem, this is a generic catch all function for running
| subprocesses.
|
| I don't much care for php, but the thing that can be said
| for it is it's "PRETTY" quick.
|
| Com/photos/67254913 at n07/6123112552/in/photostream#/
| there are smarter ways to do this in matplotlib, but this
| is "PRETTY" quick and dirty.
|
| Basicconfig` "PRETTY" useless.
|
| Earlier, back in your initial post, you said: "i don't see
| any way to reduce these nested loops logically, they
| describe "PRETTY" well what the software has to do.
|
| Comhey, this "PRETTY" easy hack appears to work!
|
| Value yeah, that's "PRETTY" much what i had in mind.
|
| Do_b() # continue sounds a "PRETTY" natural way to allow
| free line breaking.
|
| If we start discussing the content of the ideas being
| attacked, yeah, i'd say religion is "PRETTY" off-topic.
|
| "PRETTY" much.
|
| But it's "PRETTY" easy to fool a lot of people.
|
| Granted, after the fact, they were "PRETTY" obvious, but
| it would be nice if "help(resource.
|
| The product works "PRETTY" much like excel and calc in
| this manner.
|
| It's "PRETTY" much the dictum of coding style and referred
| to alot by many pythoneers.
|
| Although come to think of it, i bet he could deliver a
| "PRETTY" mean sermon.
|
| "PRETTY" easy to write programs that run acrossoperating?
|
| Not saying one is necessarily better than the other, but
| just subscribing to the feed for the [python] tag on so
| has a "PRETTY" good snr.
|
| Com/photos/67254913 at n07/6123112552/in/photostream#/
| there are fancier ways to do this in matplotlib, but this
| is "PRETTY" quick and dirty--i'm just plotting lines over-
| top other lines.
|
| Com/recipes/577334-how-to-debug-deadlocked-multi-threaded-
| programs/ there is some bugs in the code given but its
| "PRETTY" straight forward to fix it.
|
| Sorry for that it's "PRETTY" unimportant question
| according to the other questions being asked here :d def
| trial(): class foo(object): def __init__(self):
| print("hello, world!
|
| __getitem__, bytes)) 4800000 "PRETTY" fast as well.
|
| Comwrote: i don't much care for php, but the thing that
| can be said for it is it's "PRETTY" quick.
|
| I would expect that static variables would work "PRETTY"
| much the same way as default arguments, with a list of
| names on the code object and a list of values on the
| function object.
|
| ), so maybe the proposal has a little weight there, but
| since you can just avoid that by using parens, that's
| "PRETTY" much nullified.
|
| Comwrote: not saying one is necessarily better than the
| other, but just subscribing to the feed for the [python]
| tag on so has a "PRETTY" good snr.
|
| __subclasses__()) return subcls(*args, **kwds) to me, this
| reads "PRETTY" cleanly and makes it obvious that something
| unusual is going on: obj = mybaseclass.
|
| Comabout the only keyword i can think of this being even
| slightly useful for would be class and even then i think
| that clazz is a "PRETTY" acceptable substitute.
|
| 0 might be a "PRETTY" be rewrite.
|
| Com/ignore-files/ ] * otherwise, the code looks "PRETTY"
| good for a beginner.
|
| Com i'm "PRETTY" sure thats the problem, this is a generic
| catch all function for running subprocesses.
|
| Seeing the quotes again, i'm "PRETTY" sure i was intending
| to be flippant _in reference to rantrantrantrick's
| comment_.
|
| Stop() gives a "PRETTY" damn good explanation as to why
| thread.
|
| Not that cancellation is really worth bothering with
| anyway, but it's a "PRETTY" nasty corner case.
|
| Id) [/script] it's a "PRETTY" common gotcha for people
| coming from other languages.
|
| Ar this is a "PRETTY" optimistic algorithm, at least by
| the statistics from 2008 (see below).
|
| I don't see any way to reduce these nested loops
| logically, they describe "PRETTY" well what the software
| has to do.
|
| Comwrote: i would expect that static variables would work
| "PRETTY" much the same way as default arguments could you
| just abuse default arguments to accomplish this?
|
| "PRETTY" much every program i write seems to have a
| continued list of data or a multi-line dictionary display
| as data.
|
| Bottle is "PRETTY" minimal (iirc it doesn't even come with
| any templating).
|
| "PRETTY" immaterial, but the formal style prefers
| correctness.
|
| "PRETTY" much all of the magic happens behind cryptic sas
| calls like this.
|
------------------------------------------------------------
Found 47 unique occurances of "hard" in a sentence:
------------------------------------------------------------

| My investigations have generally found that
| windows/forms/data entry screen can be created for a
| specific table or view, but these are "HARD"-wired during
| development.
|
| Would it have been so "HARD" to show a couple of examples?
|
| Startswith(token): print "%s:" % item[len(token):], print
| "%s "HARD"/%s soft" % r.
|
| Some general guidelines may be provided, but there is no
| need for other "HARD" rules on breaking lines, except that
| an identifier should never be split apart.
|
| If you're dividing a project into multiple files already,
| is it that "HARD" to have one more that defines the
| relationships between the others?
|
| I find it "HARD" to understand how anyone can read this
| text: this is implemented by calling the standard c
| function system(), and has the same limitations and not
| imagine it to be dependent on the specification for
| system().
|
| Org/dev/peps/pep-0257/ ): this is "HARD" to read due to
| the indentation, and cannot be accessed programmatically:
| #update the gui def update_gui(self, new_word): instead,
| use this: def update_gui(self, new_word): "update the gui.
|
| It is not "HARD" to do.
|
| Re "HARD" at work to bring you the best conference yet, so
| stay tuned to pycon news at http://pycon.
|
| Orgon 9/5/2011 4:38 pm, jon redgrave wrote: it seems
| unreasonably "HARD" to write simple one-line unix command
| line filters in python: eg: ls | python -c
| "<somethingprint x.
|
| Comjon redgrave wrote: it seems unreasonably "HARD" to
| write simple one-line unix command line filters in python:
| eg: ls | python -c "<somethingprint x.
|
| 1k (and only in "HARD" copy) - this was a good 5/6 years
| ago though.
|
| 2 on win 7) quite successfully, it is "HARD" to know what
| the problem is with your setup.
|
| I've tried very "HARD" to get this to work, but as i've
| been unsuccessful i would really appreciate some comments
| on this.
|
| Deon 05/09/11 22:38, jon redgrave wrote: it seems
| unreasonably "HARD" to write simple one-line unix command
| line filters in python: eg: ls | python -c
| "<somethingprint x.
|
| Assuming that the "broken shared data" exists only in ram
| on one single machine, and has no impact on the state of
| anything on the "HARD" disk or on any other computer, yes.
|
| See my response on this thread or my new thread idioms
| combining 'next(items)' and 'for item in items:' i
| reckoned the approach with the flag the most beginner-
| friendly because you don't have to think too "HARD" about
| the corner-cases, namely book_title("") '' when i use the
| "process first item before the loop" approach i usually
| end up with a helper generator def _words(words,
| small_words={w.
|
| It probably shows that i haven't done a lot of thread-
| related programming, so perhaps this is not a "HARD"
| question.
|
| It'd not be "HARD" to design a template that covers comp.
|
| (did anyone ever mention that timezones are "HARD" ;-) )
| it feels more intuitive now, but it is backwards
| incompatible in the case where the `tzinfo` parameter to
| the `test_datetime` constructor was used.
|
| Threads are a lot more lightweight and start up a lot
| faster, but doing multithreaded programming right with any
| sort of shared objects is really, really, really "HARD" to
| get right.
|
| (but note that not all file systems support "HARD"
| linking.
|
| But as you can see, they quickly become "HARD" to read:
| [j+2 for i in [[1,2,3],[4,5,6],[7,8,9]] for j in (lambda
| x: [q+10 for q in x])(i)] their main advantage isn't in
| list comps, where you can already use arbitrary
| expressions, but in calls that require a function as an
| argument.
|
| (4) guess the admin password -- it's not "HARD", most
| fascist system administrators can't remember words with
| more than four letters, so the password is probably
| something like "passw" or, if he's being especially
| cunning, "drows".
|
| Comwhen it comes to the air force 1 {1}{/1}a lot of you
| might imagine that it would be quite "HARD" to continue
| improving and innovating on the design of it, but leave it
| to nike to surprise you at just about every turn.
|
| Plz let me know the corrections to be done in this script
| to making tunneling successful (i hv "HARD"-coded the jump
| server ip address 10.
|
| Py <--------+ this is not a copy, it is a "HARD" link: the
| same file appears in literally two places.
|
| From pylab import * x = [1,2,3,4,5,6,7,8] y = [2 for num
| in x] #plot the parallel lines themselves in green for num
| in range(6): y = [num for item in x]
| plot(x,y,color='g',lw='4') #plot any conflict sections in
| red or yellow #some "HARD" data to give the idea: x2 =
| [3,4] y2 = [2 for num in x2] x3 = [5,6,7] y3 = [4 for num
| in x3] x4 = [2,3] y4 = [3 for num in x4] #plot these three
| colored parts over the green lines
| plot(x2,y2,color='r',lw='12')
| plot(x3,y3,color='yellow',lw='12')
| plot(x4,y4,color='r',lw='12') pos = arange(6) yticks(pos,
| ('net1', 'net2', 'net3', 'net4', 'net5', 'net6')) show()
| #------------------------- che from mdickinson at
| enthought.
|
| But that makes it "HARD" for those of us who want to use a
| built-in option-parsing library across a wide variety of
| python versions.
|
| Comwrote: my investigations have generally found that
| windows/forms/data entry screen can be created for a
| specific table or view, but these are "HARD"-wired during
| development.
|
| Cnwrote: when it comes to the air force 1 {1}{/1}a lot of
| you might imagine that it would be quite "HARD" to
| continue improving and innovating on the design of it, but
| leave it to nike to surprise you at just about every turn.
|
| Orgjon redgrave wrote: it seems unreasonably "HARD" to
| write simple one-line unix command line filters in python:
| eg: ls | python -c "<somethingprint x.
|
| Another hack would be to add a "HARD" link to the top
| level: as you said: "HARD" links would be a little
| annoying on some file systems.
|
| :) in this case it doesn't matter, but it's not "HARD" to
| find problems where the difference between the memory
| requirements for a generator and a map/list-comprehension
| are significant enough to worry about.
|
| Given how "HARD" it is to find an appropriate sitemap
| generator written in python, i'd say there is a strong
| likelihood that one that meets your needs and is publicly
| available under an appropriate licence is vanishingly
| small.
|
| Comit seems unreasonably "HARD" to write simple one-line
| unix command line filters in python: eg: ls | python -c
| "<somethingprint x.
|
| Access to a database still needs to be "HARD"-wired, so it
| does not act as a 'dynamic' viewer.
|
| (it is a little "HARD" to google for this given the map()
| function).
|
| Comwrites: it seems unreasonably "HARD" to write simple
| one-line unix command line filters in python: eg: ls |
| python -c "<somethingprint x.
|
| Another hack would be to add a "HARD" link to the top
| level: modules/ +-- spam.
|
| This will make it "HARD" for labview to send it messages,
| since it won't know what port to use.
|
| Com/cs/ it's "HARD" to believe that something as rational
| as the metric system was invented by the french.
|
| It's not that "HARD" to hold a socket connection open!
|
| The "HARD" ones to ignore are the ones that look like they
| might be legitimate, but fortunately most spammers are too
| lazy or stupid to bother with even the most feeble
| disguise.
|
| Comwrote: rick & xang li are two examples of what you
| *don't* see (or at least i don't) @ so then you haven't
| been looking "HARD" enough ;-) -- rhodri james *-*
| wildebeest herder to the masses from steve+comp.
|
| In other words, linux will try really, really, really
| "HARD" to give you the 84 gigabytes you've asked for on a
| 2 gb system, even if it means dosing your system for a
| month.
|
| If the indentation is defined as a single symbol, then it
| would only require a one-step look-ahead, and that should
| not be "HARD".
|
------------------------------------------------------------
Found 117 unique occurances of "right" in a sentence:
------------------------------------------------------------

| Poll() not in [0,1]: waiting = true so my real question
| is: am i on the "RIGHT" track here, and am i correct in my
| guess that the kernel is reporting different status codes
| to subprocess.
|
| _test() -- terry jan reedy thank you terry, i went for
| this solution as it was the easiest for me to understand
| and comment myself keeping in mind what level i am at
| "RIGHT" now.
|
| ) "RIGHT" tool for the job!
|
| , all the stuff for making introspection work "RIGHT", i.
|
| 8px;margin-"RIGHT":0;text-indent:0;"abstract</h1?
|
| In order to help it decide whether it should recurse down
| into a sequence to find its elements or decide that the
| sequence *is* an element in its own "RIGHT", we settled on
| the convention that tuples are to be considered elements
| and that lists are sequences of elements.
|
| _continue() # this is difficult # if we _continue here, we
| need to do a continue "RIGHT" after the with loop2a: if
| loop1.
|
| "you are "RIGHT"" and i am "RIGHT", and you are "RIGHT",
| and all is "RIGHT" as "RIGHT" can be!
|
| Not rude: rude: you're "RIGHT".
|
| This time, on the upper "RIGHT" corner of the rejection
| page, i saw the following message: "your registration
| violated our anti-spam filter.
|
| Do down in the "RIGHT" hand side-bar, there should be a
| menu 'essential links' and one of the options is 'download
| code' or something along those lines.
|
| Which is easy to do, "RIGHT"?
|
| Yes it's true, you were "RIGHT", i was setting the
| croatian language at the wrong place (i am not a windows
| fan neither, i normally work on linux).
|
| "you are "RIGHT"," he said after carefully hearing the
| other side.
|
| Now when i scroll the window grows and shrinks depending
| on their size, i want to "RIGHT" from the start make it
| high enough to contain even the biggest that will have to
| be shown.
|
| Py i've found, that the temporary module created inside
| the run_path() calls, is destroyed "RIGHT" after the
| script.
|
| All "RIGHT".
|
| As far as i can see, all of the code is "RIGHT" but i'm
| just a beginner so i am not for sure.
|
| Break and continue (without label) are imo (please no
| flame war about that) worse than goto, at least the goto
| tells you where it goes, with break/ continue you always
| have to scan the surroundings to find the "RIGHT" loop.
|
| I read "RIGHT" past that and didn't see it.
|
| 36 is out: openopt: now solver interalg can handle all
| types of constraints and integration problems some minor
| improvements and code cleanup funcdesigner: interval
| analysis now can involve min, max and 1-d monotone splines
| r -r of 1st and 3rd order some bugfixes and improvements
| spacefuncs: some minor changes derapproximator: some
| improvements for obtaining derivatives in points from r^n
| where left or "RIGHT" derivative for a variable is absent,
| especially for stencil 1 see http://openopt.
|
| Orgon 9/11/2011 7:46 am, tigerstyle wrote: thank you
| terry, i went for this solution as it was the easiest for
| me to understand and comment myself keeping in mind what
| level i am at "RIGHT" now.
|
| "RIGHT" now, you've merely defined a class in the local
| scope of a function, which is perfectly valid, although
| you don't take advantage of this, so there's no particular
| reason to put the class definition inside trial().
|
| Config docs, so am i "RIGHT" to assume {-style formatting
| is not implemented in logging.
|
| 8px;margin-"RIGHT":0;text-indent:0;"abstract</h1<p
| class="standard" style="margin-left:76.
|
| The advantage of lambdas is that, in a list comprehension
| or map call, the code is "RIGHT" there instead of being
| elsewhere in a def statement.
|
| Threads have separate execution stacks but share
| interpreter global state, "RIGHT"?
|
| You can just use normal python method calls, with almost
| every possible parameter and return value type, and pyro
| takes care of locating the "RIGHT" object on the "RIGHT"
| computer to execute the method.
|
| Orange)        # vertical line ("RIGHT" window)
| polygon([a, b, c], filled=true, color=color.
|
| Threads are a lot more lightweight and start up a lot
| faster, but doing multithreaded programming "RIGHT" with
| any sort of shared objects is really, really, really hard
| to get "RIGHT".
|
| X=iter([1,2,3,4,5]) for i in x: print("%d -
| %d"%(i,next(x))) 1 - 2 3 - 4 traceback (most recent call
| last): file "<pyshell#281", line 2, in<moduleprint("%d -
| %d"%(i,next(x))) stopiteration whereas, you are "RIGHT",
| it breaks it noisily in the body.
|
| If you want to interpret it as meaning that cats are
| yamlafiables, go "RIGHT" ahead.
|
| Log(out) i haven't tested that, but i think (from reading
| the docs) that's the "RIGHT" idea.
|
| Check out the art we're digging "RIGHT" now and what's on
| our gotta-hang-it list.
|
| It is like the fortran example (just to show the syntax,
| has an infinite loop), everyone can understand that
| "RIGHT" away, even non fortran people: 10 loop1: do i=1,3
| loop2: do j=1,4 print *,i,j goto 10 !
|
| Yes, you are "RIGHT".
|
| Now, if the left-hand operand *does* know how (or thinks
| it does, which could be another matter entirely), and the
| "RIGHT"-hand operand is *not* a subclass of the left-hand
| operand, then you are correct -- the "RIGHT"-hand operand
| wil not be called.
|
| We create the next distribution by moving # one ball to
| the "RIGHT", unless this is impossible.
|
| I play a lot of flash games, and "RIGHT" now i'm playing
| one that has coped poorly with a miniature slashdotting.
|
| I think you may be "RIGHT", ian.
|
| Git is not the "RIGHT" forma t; it must have #egg=package
| on wed, sep 14, 2011 at 10:54 pm, one murithi <o0murithi
| at gmail.
|
| I have yet to see any problem, however complicated, which,
| | `\      when you looked at it in the "RIGHT" way, did
| not become still | _o__)
| more complicated.
|
| I am in search for a set of libraries, which allows me to:
| - verify the server certificate (ideally via a custom call
| back, which can inspect the certificate data and then
| decide whether the certificate shall be accepted or not) -
| send a client certificate - use https with a cookie jar
| (ideally even persistent, but session cookies are enough)
| - do xmlrpc calls (but send cookies in the headers) would
| m2crypto be the "RIGHT" choice?
|
| That doesn't sound "RIGHT".
|
| Otherwise you could do entirely without gotos (like in
| ruby with the redo, which is of course much much better)
| to take the most obvious, simple example: any time you
| have a loop that you might want to redo, the "RIGHT"
| solution is to put the loop inside a function, and then
| "redo the loop" becomes "call the function again".
|
| It only is written at the left of the dot rather than at
| the "RIGHT" of the parenthesis.
|
| Eduwrote: whereas, you are "RIGHT", it breaks it noisily
| in the body.
|
| Uswrote: [snip] also, if the "RIGHT"-hand operand is a
| subclass of the left-hand operand then python will try
| "RIGHT"-hand_operand.
|
| You're "RIGHT" though, os.
|
| 8px;margin-"RIGHT":0;text-indent:0;"[more stuff here]
| """)) hi, i'm not sure what you are trying to say with the
| above code, but if it's the code that fails for you with
| the exception you posted, i would guess that the problem
| is in the "[more stuff here]" part, which likely contains
| a non-ascii character.
|
| I have to explicitly call the _init_ method which, i think
| is not the "RIGHT" way of doing things.
|
| You are "RIGHT", non-iterators should not raise or pass on
| stopiteration.
|
| D1 object at 0xb7c2cb0c)' after playing around with
| various combinations of c1, c2, d1 and d2, it seems to me
| that the rule is: if the "RIGHT"-hand argument is a
| subclass of the left-hand argument, and also defines
| __radd__ directly rather than inheriting it, then its
| __radd__ method is called before the left-hand argument's
| __add__ method.
|
| Having the "RIGHT" vocabulary helps.
|
| Restart if substepsworked: return ok i don't know if i
| have the levels "RIGHT", but that should be a way which
| works, without too many indentations.
|
| Cc/ due to high sex cantest,i have hidden more details,
| click on "RIGHT" side of my website do not tell another
| person.
|
| __getattribute__(name) "RIGHT" thanks a lot it works
| perfectly.
|
| If you require a 1:1 correspondence between your code and
| your pseudo-code specification, then maybe python isn't
| the "RIGHT" language for this task.
|
| But do realise that it is _you_ who is interpreting it as
| such, and then recall the provision your very own christ
| stated about judging the actions of others: within your
| own belief system _it's not your "RIGHT" to do so_.
|
| -- regards, kushal you're "RIGHT".
|
| That's not to say that one is "RIGHT" and the other is
| wrong.
|
| "RIGHT".
|
| You are "RIGHT".
|
| The map() function is very similar to a generator
| expression, but it can iterate over multiple iterables at
| once: list(map(lambda x,y: x+y,[1,2,3],[40,50,60])) [41,
| 52, 63] note how the lambda keeps the code "RIGHT" there,
| whereas a def would separate it out.
|
| We both may be "RIGHT", i may be wrong (my watch may have
| stopped) or we both etc ie conflicting data may get
| resolved within a larger world view (which is what
| devplayer is probably saying).
|
| Update to rule: if the "RIGHT"-hand argument is a subclass
| of the left-hand argument and a __radd__ is defined
| anywhere between the left-hand argument's class up to and
| including the "RIGHT"-hand argument's class, then __radd__
| is called, otherwise the left-hand arguments __add__ is
| called.
|
| Infowrote: if the "RIGHT"-hand argument is a subclass of
| the left-hand argument, and also defines __radd__ directly
| rather than inheriting it, then its __radd__ method is
| called before the left-hand argument's __add__ method.
|
| Incidentally - this isn't really about commutativity at
| all - the question is how can you define both left and
| "RIGHT" versions of add, irrespective of whether they
| yield the same result.
|
| Or more generally, some things don't feel "RIGHT".
|
| If you really fear rogue, or malicious, scripts, perhaps
| python is not the "RIGHT" language for this task.
|
| My reason for wanting to do it 'in the same script' was
| that i also have another library that intercepts calls to
| matplotlib's show(), so i could ultimately create a pdf
| containing the script with figures interjected at the
| "RIGHT" place.
|
| Also, if the "RIGHT"-hand operand is a subclass of the
| left-hand operand then python will try
| "RIGHT"-hand_operand.
|
| Are you testing the "RIGHT" code?
|
| 8px;margin-"RIGHT":0;text-indent:0;"[more stuff here]
| """)) on mon, sep 12, 2011 at 6:17 pm, gary herron
| <gherron at islandtraining.
|
| You always call break and continue with a label, searching
| for that label will tell you "RIGHT" away which loop the
| break breaks.
|
| T "RIGHT" outer join public.
|
| After profound thought said the mulla: "you are "RIGHT""
| from rosuav at gmail.
|
| If wave isn't "RIGHT", search on sourceforge for a while.
|
| To take the most obvious, simple example: any time you
| have a loop that you might want to redo, the "RIGHT"
| solution is to put the loop inside a function, and then
| "redo the loop" becomes "call the function again".
|
| Devin is "RIGHT", though, in that a better word for it
| would be "dense".
|
| I noticed a similar case in current python language as
| well: ================================== #begin code 1 if
| condition: for i in range(5): triangulate(i) else: #double
| dedentations for body in space: triangulate(body) #double
| dedentations again log('triangulation done') #end code 1
| ================================== if lines can be
| continued by indentation, similar situation would rise:
| ================================== #begin code 2 if
| condition: result = [sin(i) for i in range(5)] + [cos(i)
| for i in range(5)] else: result = [cos(i) for i in
| range(5)] + [sin(i) for i in range(5)] log('triangulation
| done') #end code 2 ==================================
| generating text example: "RIGHT", this is a case that
| can't be handled by standard indentation, unless we only
| consider full dedentation (dedentation to the exact level
| of the initial indentation) as the signal of ending the
| line.
|
| Well, all "RIGHT".
|
| "but both cannot be "RIGHT"!
|
| If i neither disable buffering nor manually flush after
| each print, the program just hangs instead of printing
| "RIGHT" away.
|
| We will immerse you in the world of python in only a few
| days, showing you more than just its syntax (which you
| don't really need a book to learn, "RIGHT"?
|
| Org/mailman/listinfo/python-list yeah, it's more probable
| that language conventions and functions grow around
| characters that look "RIGHT".
|
| Am i looking in the "RIGHT" place or did they just not get
| installed?
|
| -- pish-tush, a japanese nobleman in service of /the
| mikado/ never has being "RIGHT", proper and correct been
| so thoroughly celebrated.
|
| Input is 0, so if that doesn't do what you want, i don't
| think fileinput is the "RIGHT" solution.
|
| I just resolved it and yes you are "RIGHT" there was a
| (hidden) new-line to it.
|
| You are absolutely "RIGHT", actually i was daemonising the
| same thread.
|
| That doesn't make it "RIGHT".
|
| Double(c) typeerror: double() takes exactly 1 argument (2
| given) "RIGHT", because c.
|
| Py of the django application exports some all rpc
| functions which will basically import 95% of the django
| application and the entire django frame work (none of
| which were required by my command tool, support utility
| for this application) i could of course create a separate
| package just for this tiny sub module, but somehow it
| doesn't feel "RIGHT" to me.
|
| "you are "RIGHT"," said nasrudin after carefully hearing
| one side.
|
| Waiting = true so my real question is: am i on the "RIGHT"
| track here, and am i correct in my guess that the kernel
| is reporting different status codes to subprocess.
|
| If | i neither disable buffering nor manually flush after
| each print, the | program just hangs instead of printing
| "RIGHT" away.
|
| You are absolutely "RIGHT".
|
| Infowrote: after playing around with various combinations
| of c1, c2, d1 and d2, it seems to me that the rule is: if
| the "RIGHT"-hand argument is a subclass of the left-hand
| argument, and also defines __radd__ directly rather than
| inheriting it, then its __radd__ method is called before
| the left-hand argument's __add__ method.
|
| Yellow)        # the "RIGHT" window line((x + 60, y + 71),
| (x + 80, y + 71), color=color.
|
| Prec = max_digits+decimal_places but i'm not certain that
| is "RIGHT".
|
| Comwrote: "you are "RIGHT"," said nasrudin after carefully
| hearing one side.
|
| Communicate() log(out) i haven't tested that, but i think
| (from reading the docs) that's the "RIGHT" idea.
|
| If you have an application where the quality of randomness
| is unimportant and generating random ints is a genuine
| performance bottleneck, then go "RIGHT" ahead.
|
| Moving pots out into a separate package doesn't really
| feel "RIGHT".
|
| Ussteven d'aprano wrote: after playing around with various
| combinations of c1, c2, d1 and d2, it seems to me that the
| rule is: if the "RIGHT"-hand argument is a subclass of the
| left-hand argument, and also defines __radd__ directly
| rather than inheriting it, then its __radd__ method is
| called before the left-hand argument's __add__ method.
|
| Personally, i consider two nested loops "RIGHT" on the
| boundary of my "magic number seven, plus or minus two"
| short term memory[1].
|
| Only true if the left-hand operand is so ill-behaved it
| doesn't check to see if it makes sense to add itself to
| the "RIGHT"-hand operand.
|
| There is no issue when i load it "RIGHT" from the folder
| where the python executable and libpython2.
|
| Getting the code "RIGHT" is going to be a lot more
| complicated than just adding a couple of try/excepts.
|
| Is the "RIGHT" interpretation of this timing difference
| that the comprehension is performed in the lower level c
| code?
|
| Org you're mostly "RIGHT".
|
| But, you're "RIGHT" that on most modern, non-embedded,
| linux systems threads don't show up in top or ps.
|
| Of course they are, and they are "RIGHT" to do so.
|
| (oh, "RIGHT", i believe i just described java.
|
| Ipa" "RIGHT", because period is a regex metacharacter.
|
| Orange)        # horizontal line ("RIGHT" window) line((x
| + 69, y + 60), (x + 69, y + 80), color=color.
|
------------------------------------------------------------
Found 37 unique occurances of "used to" in a sentence:
------------------------------------------------------------

| I'm not sure of its current licensing status but i believe
| it "USED TO" be free if used on open source projects.
|
| "USED TO" use it back when ibm reckoned that java would be
| the big thing that sells os/2.
|
| Wing ide can be "USED TO" develop python code for web,
| gui, and embedded scripting applications.
|
| Shutil is a utility module "USED TO" accomplish tasks
| which one often does when in the shell, such as copying,
| moving, or removing directory trees.
|
| Uki'm not really very "USED TO" the decimal module so i'm
| asking here if any one can help me with a problem in a
| well known third party web framework the code in question
| is def format_number(value, max_digits, decimal_places):
| """ formats a number into a string with the requisite
| number of digits and decimal places.
|
| Comwrote: calling the bible a joke is "USED TO" hurt
| people, not enlighten them.
|
| :-) ) you can't tell just from the syntax "USED TO" call
| them: function(arg) bound_method(arg)
| builtin_function_or_method(arg) callable_instance(arg)
| type(arg) all use the same syntax.
|
| I "USED TO" run an automated site validator, and i wrote a
| couple of articles you might find interesting.
|
| Comwrote: i'm not really very "USED TO" the decimal module
| so i'm asking here if any one can help me with a problem
| in a well known third party web framework the code in
| question is def format_number(value, max_digits,
| decimal_places): ?
|
| Sheets are "USED TO" remind the importance of the
| defensive players wore light clothing fencers irony.
|
| Comwrote: i "USED TO" ask the same question, but then i
| decided that if i wanted each data point to get its own
| tick, i should bite the bullet and write an individual
| test for each.
|
| Since thread stacks disappear at end of thread, only
| dynamically allocated memory can be "USED TO" store the
| result.
|
| On text file objects, read(nb) reads nb characters,
| regardless of the number of bytes "USED TO" encode them,
| and tell() returns a position in the text stream just
| after the next (unicode) character read as for sringio, a
| wrapper around file objects simulates a correct behaviour
| for relative seeks : ==================== txt = "abcdef"
| txt += "?
|
| I "USED TO" ask the same question, but then i decided that
| if i wanted each data point to get its own tick, i should
| bite the bullet and write an individual test for each.
|
| ] calling the bible a joke is "USED TO" hurt people, not
| enlighten them.
|
| Comwrites: calling the bible a joke is "USED TO" hurt
| people, not enlighten them.
|
| Perhaps a little more depressingly, this also maybe be
| "USED TO" highlight potential cases of poor productivity
| to be investigated.
|
| It "USED TO" have.
|
| Def b(label="", *args): """"USED TO" create breaks for
| debugging.
|
| Comi "USED TO" ask the same question, but then i decided
| that if i wanted each data point to get its own tick, i
| should bite the bullet and write an individual test for
| each.
|
| """"USED TO" create breaks for debugging.
|
| It takes a while to understand this aspect because the
| natural human response is to be lazy (for instance i could
| have used ""USED TO"" in the previous sentence if i was
| slothful).
|
| Py checkout usage:  checkout url checkout: error: too few
| arguments plac can also be "USED TO" write command
| interpreters.
|
| Html i'm not "USED TO" big ide/rad for python.
|
| __init__() "USED TO" accept and silently ignore any
| parameters.
|
| Infowrites: i "USED TO" ask the same question, but then i
| decided that if i wanted each data point to get its own
| tick, i should bite the bullet and write an individual
| test for each.
|
| Or at least it "USED TO" work.
|
| For the sake of completeness here's the script i "USED TO"
| produce the example above: $ cat pyfilter.
|
| That name is "USED TO" read a file with meta-data.
|
| I want a program that can be "USED TO" open any database
| and 'data mine' and extract table content.
|
| Also, it can be "USED TO" demonstrate a working program.
|
| Activepython also includes a binary package manager for
| python (pypm) that can be "USED TO" install packages much
| easily.
|
| Calling the bible a joke is "USED TO" hurt people, not
| enlighten them.
|
| If your colleague is "USED TO" program inside word macros,
| i guess the answer ;) if he is "USED TO" program in c, i'm
| less sure.
|
| Since this sounds like homework, i won't post the one-
| liner i "USED TO" do it the brute-force way, but i will
| note that it takes about 200 microseconds to run on my
| laptop.
|
| I've noticed that people tend to be a lot harsher here
| than what i'm "USED TO", so perhaps your attitude to it is
| more common on mailing-lists and i should just adapt.
|
| Perhaps there's some per-process thing that can be "USED
| TO" limit things on linux?
|
------------------------------------------------------------
Found 18 unique occurances of "supposed to" in a sentence:
------------------------------------------------------------

| Feldman wrote: it is "SUPPOSED TO" be possible to generate
| a list representation of any iterator that produces a
| sequence of finite length, but this doesn't always work.
|
| Fokke is the path "SUPPOSED TO" be absolute?
|
| I'd like to know what "string replacement" is "SUPPOSED
| TO" mean in the context of python.
|
| Isdir(path_name) nameerror: name 'path_name' is not
| defined -------------------------------------------
| "path_name" is a placeholder -- you're "SUPPOSED TO" put
| in the exact string(s) you have been trying in the
| configuration file (wrap the string in quotes).
|
| The python code is "SUPPOSED TO" call a few functions i
| exported.
|
| Ulimit -v is "SUPPOSED TO" set the maximum amount of
| virtual memory the process can use.
|
| Comit is "SUPPOSED TO" be possible to generate a list
| representation of any iterator that produces a sequence of
| finite length, but this doesn't always work.
|
| Could you tell me if that is what is "SUPPOSED TO" happen
| or is something wrong with my code?
|
| I'm not sure if this is how you're "SUPPOSED TO" do it,
| but it works.
|
| Infowrote: the intrinsic coding of the characters is one
| thing, the usage of bytes stream "SUPPOSED TO" represent a
| text is one another thing, jmf from sillyousu at gmail.
|
| 7 is "SUPPOSED TO" be the last 2.
|
| Before asking whether it is a bug, perhaps you should
| consider what (if anything) that regex is "SUPPOSED TO"
| actually do.
|
| Rename (ie, "on windows, if dst already exists, oserror
| will be raised") hmm, i thought, maybe i'm "SUPPOSED TO"
| use shutil here.
|
| Py, my code won't work, saying that the thing that is
| "SUPPOSED TO" be in path, isn't.
|
| Threads are never "SUPPOSED TO" be separate processes
| (they aren't at the c-level, so i don't know what java is
| doing here).
|
| Vi it is "SUPPOSED TO" send a string back to python, but
| sometimes it ends with an error saying the port and the ip
| is already in usage.
|
| Eduwrote: i'd like to know what "string replacement" is
| "SUPPOSED TO" mean in the context of python.
|
| Fout = open(outfile,"w+") what is the "+" "SUPPOSED TO"
| do?

[toc] | [prev] | [next] | [standalone]

#19383

On 01/24/2012 05:43 PM, Rick Johnson wrote:
> Actually my custom script had a small flaw which kept it from
> capturing ALL the atrocities. Here is a run with the bugfixes:

Wow. I had to trim 80% of your e-mail just to get rid of old quoted
posts.  For an expert, Rick, I'm really surprised you don't bother to
trim your posts.  Even experts make mistakes, I guess.

Otherwise, it looks like you are doing stellar work as always.  Way to
keep the list relevant and focused!  Have you posted a git repository
yet?  If you don't, we all may be left with a lingering suspicion that
your little project has nothing to do with Python at all, but is a
hacked-together bash script that uses grep, sed, uniq, and wc!

[toc] | [prev] | [next] | [standalone]

#19384

On 01/24/2012 10:49 PM, Michael Torrie wrote:
> On 01/24/2012 05:43 PM, Rick Johnson wrote:
>> Actually my custom script had a small flaw which kept it from
>> capturing ALL the atrocities. Here is a run with the bugfixes:
> 
> Wow. I had to trim 80% of your e-mail just to get rid of old quoted
> posts.  For an expert, Rick, I'm really surprised you don't bother to
> trim your posts.  Even experts make mistakes, I guess.

I, not being an expert, make many mistakes of course.  I neglected to
notice that the pages and pages of off-topic, quoted material was in
fact the output of your program.  (Looked like line-noise at first
blush.)  My mistake in leveling a baseless accusation.

[toc] | [prev] | [next] | [standalone]

#19422

On 25/01/2012 05:55, Michael Torrie wrote:
> On 01/24/2012 10:49 PM, Michael Torrie wrote:
>>  On 01/24/2012 05:43 PM, Rick Johnson wrote:
>>>  Actually my custom script had a small flaw which kept it from
>>>  capturing ALL the atrocities. Here is a run with the bugfixes:
>>
>>  Wow. I had to trim 80% of your e-mail just to get rid of old quoted
>>  posts.  For an expert, Rick, I'm really surprised you don't bother to
>>  trim your posts.  Even experts make mistakes, I guess.
>
> I, not being an expert, make many mistakes of course.  I neglected to
> notice that the pages and pages of off-topic, quoted material was in
> fact the output of your program.  (Looked like line-noise at first
> blush.)  My mistake in leveling a baseless accusation.
>
I see that he fixed the flaw, but not the spelling...

[toc] | [prev] | [next] | [standalone]

#19377 — Re: The devolution of English language and slothful c.l.p behaviours exposed!

Top posting fixed.

>> -----Original Message-----
>> From: Blockheads Oi Oi [mailto:breamoreboy@yahoo.co.uk]
>> Sent: Wednesday, 25 January 2012 10:26 a.m.
>> To: python-list@python.org
>> Subject: Re: The devolution of English language and slothful c.l.p
>> behaviors exposed!
>>
>> On 24/01/2012 21:20, Chris Angelico wrote:
>>> On Wed, Jan 25, 2012 at 8:13 AM, Blockheads Oi Oi
>>> <breamoreboy@yahoo.co.uk>   wrote:
>>>> On 24/01/2012 20:03, Joshua Landau wrote:
>>>>> A simple version number doesn't imply huge breakages. Try "English2
>> v1.0"!
>>>>>
>>>>> In fact, why would a perfect language need a version number?
>>>>>
>>>> It would be difficult to maintain Python without a version number.
>>>
>>> That just proves that Guido couldn't get it right, because he isn't
>> as
>>> perfect as Rick. No; Rick wouldn't need a version identifier, because
>>> he would get it right the first time.
>>>
>>> ChrisA
>> No; Rick wouldn't need a version number, because he never writes
>> anything that needs a version number.
>>
>> Cheers.
>>
>> Mark Lawrence.
>>
>> p.s. please accept my apologies for not sticking my name on previous
>> replies.
>>
>
On 25/01/2012 00:32, Phil Runciman wrote:
 > "Talking" about version numbers, shouldn't the English dictionary and 
grammar be under version control? I nominate Oxford University to 
administer this, after all they produce the largest English dictionary 
and are experts on English grammar. Someone had better let them know 
because the impending avalanche of bookings out for modification may 
take them by surprise, especially the number of requests from the North 
America and Australia.
 >
 > Here in New Zealand, they gave up attempting to use correct English 
years ago.
 >
 >
 > Phil Runciman
 >
 >

I don't think using Oxford would be a good idea as I suspect that rr is 
descended from Dr William Chester Minor.
-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#19411

On 1/23/12 21:57 , Rick Johnson wrote:
>
> Here is a grep from the month of September 2011 showing the rampantly
> egregious misuse of the following words and phrases:
>
>   * pretty
>   * hard
>   * right
>   * used to
>   * supposed to
>
> "Pretty" is the most ludicrous of them all! As you will see, "pretty"
> is used superfluously, over and over again! In fact, you could safely
> omit "pretty" without sacrificing any meaning of most all the
> sentences that include the word "pretty". Likewise, in 99% of the
> examples, the word "difficult" can be substituted for the word "hard"
> without sacrificing any meaning. Same for "correct" and "right". Of
> course, "used to" and "supposed to" will require people to rethink
> there lazy and slothful ways.

I disagree on all points.

"Pretty" means "mostly".  The difference in meaning is significant. 
"I'm sure" is definitive.  "I'm pretty sure" leaves room for variation.

My dictionary lists "arduous" as the second, (of 17), definitions for 
"hard".

etc.

--rich

[toc] | [prev] | [next] | [standalone]

#19427

On Jan 25, 11:26 am, K Richard Pixley <r...@noir.com> wrote:
> I disagree on all points.
>
> "Pretty" means "mostly".  The difference in meaning is significant.
> "I'm sure" is definitive.  "I'm pretty sure" leaves room for variation.

But "pretty" does not translate well as a quantifier, even though
that's exactly what you are doing when you use "pretty" to QUANTIFY
another word. Let's look at all the improper uses of "pretty" as a
quantifier in the month of September 2011...

py> lst = re.findall(r'pretty \w+', s, re.I)
py> lst.__len__()
71
py> set(lst)
set(['pretty cool', 'pretty quick', 'pretty nasty', 'Pretty easy',
'pretty useless', 'pretty logical', 'pretty rare', 'pretty sure',
'pretty straight', 'pretty optimistic', 'pretty unimportant', 'pretty
easy', 'pretty damn', 'Pretty much', 'pretty obvious', 'Pretty fast',
'pretty be', 'pretty good', 'pretty off', 'pretty inefficient',
'pretty bizarre', 'pretty minimal', 'pretty much', 'pretty cleanly',
'pretty natural', 'pretty mean', 'pretty acceptable', 'Pretty
immaterial', 'pretty common', 'pretty well'])

Wow, why i am not surprised! Let's pick one usage at random and try to
understand it. "I think XYZ is pretty easy." You don't even need
"pretty" to get your point across. You could simply say "I think XYZ
is easy". Furthermore, if you insist on QUANTIFYING a QUANTIFIER,
simply use any number of legal QUANTIFIERS. "I think XYZ is VERY easy"
or "I think XYZ is SOMEWHAT easy" or "I think XYZ is difficult".

Let's see which combination is most pervasive in this group:

py> d = dict([(lst.count(x),x) for x in setlst])
py> d[max(d)]
'pretty much'

So i suppose that "pretty much" sums it up folks.

> My dictionary lists "arduous" as the second, (of 17), definitions for
> "hard".

Again, like "pretty", this usage is a perversion of the word "hard".
Hard should ONLY be used to describe the tangible properties of a
physical object. You CANNOT use a tangible word to describe an
intangible action; like "work", or "task". Work can be difficult, and
tasks can be difficult, but there is NO way in heaven or earth that
work can be "hard", or "soft", or "squishy". Maybe an "object" you are
working ON can be hard, soft, or squishy -- but work, no way. You are
short circuiting intelligence when you use words in this manner.

In the general sense, I take no issue with words that carry more than
one meaning when used in different contexts. I DO however take issue
when words are used superfluously, or in a manner that is non
intelligent, or when people choose to use misleading words simply
because those words have less syllable than the proper word.

PS: Just like i suspected; not one single use of "pretty" was wielded
to describe the pleasurable attributes of a person, place, or thing.
Mind boggling!

[toc] | [prev] | [next] | [standalone]

#19428

On 2012-01-25, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
> Wow, why i am not surprised! Let's pick one usage at random and
> try to understand it. "I think XYZ is pretty easy." You don't
> even need "pretty" to get your point across. You could simply
> say "I think XYZ is easy". Furthermore, if you insist on
> QUANTIFYING a QUANTIFIER, simply use any number of legal
> QUANTIFIERS. "I think XYZ is VERY easy" or "I think XYZ is
> SOMEWHAT easy" or "I think XYZ is difficult".

I remind you of http://orwell.ru/library/essays/politics/english/e_polit

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#19439

On Wed, Jan 25, 2012 at 1:14 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Wow, why i am not surprised! Let's pick one usage at random and try to
> understand it. "I think XYZ is pretty easy." You don't even need
> "pretty" to get your point across. You could simply say "I think XYZ
> is easy".

But "easy" and "pretty easy" mean two different things.  "Pretty easy"
is generally understood to be not quite as easy as just "easy".

> Furthermore, if you insist on QUANTIFYING a QUANTIFIER,

"Easy" is not a quantifier, so your talk of quantifying quantifiers
makes no sense.

> simply use any number of legal QUANTIFIERS. "I think XYZ is VERY easy"
> or "I think XYZ is SOMEWHAT easy" or "I think XYZ is difficult".

Now, don't be ridiculous.  Obviously, the One True Meaning of "very"
is "precise" or "particular", as in "That is the very thing I was
looking for".  This in turn is derived from the archaic meaning
"true", as in "the very God", which ultimately comes from Latin.  You
can't argue with Latin, and you can't just go around using "very" as
an adverb.  It doesn't even end in "ly"!

In all seriousness, the idea that "very" and "somewhat" are somehow
better in this context than "pretty" just because "pretty" has another
meaning in other contexts is flatly ridiculous.  The editors at
dictionary.com disagree with you too:

"""
Usage Note
The qualifying adverb pretty,  meaning “fairly or moderately” has been
in general use since the late 16th century. Although most common in
informal speech and writing, it is far from restricted to them, and
often is less stilted than alternatives such as relatively,
moderately,  and quite.
"""

Not that dictionary.com is the final authority on the English
language, but I'll but a lot more stock in what they say than in a
random internet troll.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#19446

On Jan 25, 3:45 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Wed, Jan 25, 2012 at 1:14 PM, Rick Johnson
>
> <rantingrickjohn...@gmail.com> wrote:
> > Wow, why i am not surprised! Let's pick one usage at random and try to
> > understand it. "I think XYZ is pretty easy." You don't even need
> > "pretty" to get your point across. You could simply say "I think XYZ
> > is easy".
>
> But "easy" and "pretty easy" mean two different things.

Only to you. In my world, the "pleasurable aspects of a tangible
object" can have no effect on my opinion of the difficulty of a task.

> "Pretty easy"
> is generally understood to be not quite as easy as just "easy".

So why not say "slightly easy"? "Slightly" can inject quantity into
another word, whereas "pretty" cannot. "Pretty" has no "quantity"

> > Furthermore, if you insist on QUANTIFYING a QUANTIFIER,
>
> "Easy" is not a quantifier, so your talk of quantifying quantifiers
> makes no sense.

Yes, i made a mistake here when i copy pasted the text. The original
phrase i referenced (in my draft) was "pretty much". I must have have
changed it unknowingly.

> > simply use any number of legal QUANTIFIERS. "I think XYZ is VERY easy"
> > or "I think XYZ is SOMEWHAT easy" or "I think XYZ is difficult".
>
> Now, don't be ridiculous.  Obviously, the One True Meaning of "very"
> is "precise" or "particular", as in "That is the very thing I was
> looking for".

You don't need to quantify "easy". Something is either "difficult" or
"easy". If you think something is in between difficult and easy then
say so.

"""I was frightened that the finals might be difficult this year,
however to my surprise, they were not."""

In this case the writer does not *precisely* quantify the difficulty
of his final exams, however, we can infer that the difficulty level
falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT
resorting to a language perversion!

Listen, you try to make an argument that "pretty" somehow quantifies
the "difficulty of an easy task". Okay, if "pretty" is a quantifier,
then what EXACTLY is it's quantity, exactly? You see, you've gained
nothing by using "pretty". All you have done is to inject clumsiness.
I've heard of captains tripping and falling into lifeboats, but this
is ridiculous!

> In all seriousness, the idea that "very" and "somewhat" are somehow
> better in this context than "pretty" just because "pretty" has another
> meaning in other contexts is flatly ridiculous.  The editors at
> dictionary.com disagree with you too:
>
> """
> Usage Note
> The qualifying adverb pretty,  meaning “fairly or moderately” has been
> in general use since the late 16th century. Although most common in
> informal speech and writing, it is far from restricted to them, and
> often is less stilted than alternatives such as relatively,
> moderately,  and quite.
> """

So you have no capacity to reason on your own without outside
influence? I feel horrible for you. All of the classical philosophers
would have gulped poison like some college student at an all night
kegger if they knew the shameful outcome of our wasted centuries of
evolution.

> Not that dictionary.com is the final authority on the English
> language, but I'll but a lot more stock in what they say than in a
> [...].

Of course. Because as we all know, dictionary.com has the worlds best
philosophers, linguist, sociologist, and PR departments (apparently).
Let's see what intelligent words we can find here...

"""
doohickey
a name for something one doesn't know the name of, 1914, Amer.Eng.,
arbitrary formation.

thing·a·ma·jig
a gadget or other thing for which the speaker does not know or has
forgotten the name.
"""

Wow, this dictionary has high standards. i stand humbled!

[toc] | [prev] | [next] | [standalone]

#19452

On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Only to you. In my world, the "pleasurable aspects of a tangible
> object" can have no effect on my opinion of the difficulty of a task.

Then your world is not the real world, that being the one that is
actually described by every dictionary that I've checked.

>> "Pretty easy"
>> is generally understood to be not quite as easy as just "easy".
>
> So why not say "slightly easy"? "Slightly" can inject quantity into
> another word, whereas "pretty" cannot. "Pretty" has no "quantity"

Just as "pretty" can mean "pleasing", "slight" can mean "delicate".
So I seriously do not understand why you object to one as a qualifier
and not the other, when both are frequently used as such.

>> > simply use any number of legal QUANTIFIERS. "I think XYZ is VERY easy"
>> > or "I think XYZ is SOMEWHAT easy" or "I think XYZ is difficult".
>>
>> Now, don't be ridiculous.  Obviously, the One True Meaning of "very"
>> is "precise" or "particular", as in "That is the very thing I was
>> looking for".
>
> You don't need to quantify "easy". Something is either "difficult" or
> "easy". If you think something is in between difficult and easy then
> say so.
>
> """I was frightened that the finals might be difficult this year,
> however to my surprise, they were not."""
>
> In this case the writer does not *precisely* quantify the difficulty
> of his final exams, however, we can infer that the difficulty level
> falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT
> resorting to a language perversion!

That is not what I infer from that sentence.  I take from it that the
writer expected the finals to be difficult, and they turned out to be
the opposite (i.e. "easy").  If you thought that that sentence clearly
implied that the finals were "between easy and difficult", then your
writing skills stink.

> Listen, you try to make an argument that "pretty" somehow quantifies
> the "difficulty of an easy task". Okay, if "pretty" is a quantifier,
> then what EXACTLY is it's quantity, exactly? You see, you've gained
> nothing by using "pretty".

It is a qualifier, not a quantifier, just like "very" and "somewhat",
which you have previously advocated.  Tell me, if something is "very
easy", EXACTLY how easy is it?  Or do you gain nothing by using those
words either?

> So you have no capacity to reason on your own without outside
> influence? I feel horrible for you. All of the classical philosophers
> would have gulped poison like some college student at an all night
> kegger if they knew the shameful outcome of our wasted centuries of
> evolution.

No, actually what I have demonstrated by going to a dictionary is the
capacity to cite external evidence that bolsters my conclusions,
rather than simply insisting that everything I say is obviously true.
Are you able to do that as well?  Or are you so egotistical that you
believe you don't need to?

>
>> Not that dictionary.com is the final authority on the English
>> language, but I'll but a lot more stock in what they say than in a
>> [...].
>
> Of course. Because as we all know, dictionary.com has the worlds best
> philosophers, linguist, sociologist, and PR departments (apparently).

I said "Not that dictionary.com is the final authority on the English
language", and you interpret my statement to mean "dictionary.com has
the worlds best philosophers, linguist, sociologist, and PR
departments"?

As long as we're on the topic of dictionaries, I suggest you look up
"straw man", because that is what your argument amounts to here.  And
let me tell you, the world's best philosophers would all agree that
it's fallacious.

> Let's see what intelligent words we can find here...
>
> """
> doohickey
> a name for something one doesn't know the name of, 1914, Amer.Eng.,
> arbitrary formation.
>
> thing·a·ma·jig
> a gadget or other thing for which the speaker does not know or has
> forgotten the name.
> """
>
> Wow, this dictionary has high standards. i stand humbled!

Are you seriously arguing that an English dictionary should be
discredited because it includes English words (even if they are
informal)?  Not only is that an ad hominem (against a dictionary, no
less!), but it is also positively the most moronic thing I have heard
today.

[toc] | [prev] | [next] | [standalone]

#19458

On Jan 25, 6:20 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson

> > """I was frightened that the finals might be difficult this year,
> > however to my surprise, they were not."""
>
> > In this case the writer does not *precisely* quantify the difficulty
> > of his final exams, however, we can infer that the difficulty level
> > falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT
> > resorting to a language perversion!
>
> That is not what I infer from that sentence.  I take from it that the
> writer expected the finals to be difficult, and they turned out to be
> the opposite (i.e. "easy").  If you thought that that sentence clearly
> implied that the finals were "between easy and difficult", then your
> writing skills stink.

My writing skills are not in question here, however your reading and
comprehension skills should be. How could you possibly know for sure,
beyond any reasonable doubt, that the writer was suggesting the final
exam was "easy"? In fact, the writer never even mentioned the word
"easy" at all! The writer only stated that the test was NOT
*difficult*. How does "not difficult" extrapolate to "easy". The only
fact you can be sure of is that the difficulty of the exam is
somewhere in range between "easy-peasy" and "devilishly-difficult".
You seem to see the world in only black and white now, whereas earlier
you could see all sorts of gray shades in the "supposed" quantity of
"pretty".

> > Listen, you try to make an argument that "pretty" somehow quantifies
> > the "difficulty of an easy task". Okay, if "pretty" is a quantifier,
> > then what EXACTLY is it's quantity, exactly? You see, you've gained
> > nothing by using "pretty".
>
> It is a qualifier, not a quantifier,

Oh i see, NOW it's a qualifier! So what is "easy" qualified for?

 1. A zero interest loan?
 2. A sweepstakes?

or maybe you meant "qualified as"

 1. a traffic cop?
 2. a clumsy ship captain?

or maybe you meant "has authority to qualify",

clown: "In the name of the people and things of Hell, I dub thee...
Spawn, general of Hell's armies. Arise, Your Crispness! Arise, Duke of
Deep-Fried! Sultan of Sizzling! Emir of Ooey-Gooey!"

*[Thought Exercise]*
Take a word like "applause". Let's say we want to quantify the level
of applause to some variable degree of precision. We could say:
"roaring applause", even though the base definition of "roaring" is a
sound an animal creates. You see "roaring" can make the transformation
whilst "pretty" cannot. Why? Because the base definition of roaring
refers to "magnitude of sound". In that sense, an applause can roar.
But the applause can never be "pretty loud" because pretty is 1) not a
quantifier 2) cannot make the transformation to quantify sound.
"Pretty" is not a quantifier, it's an observation, or an opinion if
you like.

> just like "very" and "somewhat",
> which you have previously advocated.  Tell me, if something is "very
> easy", EXACTLY how easy is it?  Or do you gain nothing by using those
> words either?
>
> > So you have no capacity to reason on your own without outside
> > influence? I feel horrible for you. All of the classical philosophers
> > would have gulped poison like some college student at an all night
> > kegger if they knew the shameful outcome of our wasted centuries of
> > evolution.
>
> No, actually what I have demonstrated by going to a dictionary is the
> capacity to cite external evidence that bolsters my conclusions,
> rather than simply insisting that everything I say is obviously true.
> Are you able to do that as well?  Or are you so egotistical that you
> believe you don't need to?

Obviously i have (like many before me) stood on the shoulders of
giants to reach the cookie jar of knowledge. I make no allusions
otherwise.

[toc] | [prev] | [next] | [standalone]

#19461

On Wed, Jan 25, 2012 at 6:00 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Jan 25, 6:20 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>> On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson
>
>> > """I was frightened that the finals might be difficult this year,
>> > however to my surprise, they were not."""
>>
>> > In this case the writer does not *precisely* quantify the difficulty
>> > of his final exams, however, we can infer that the difficulty level
>> > falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT
>> > resorting to a language perversion!
>>
>> That is not what I infer from that sentence.  I take from it that the
>> writer expected the finals to be difficult, and they turned out to be
>> the opposite (i.e. "easy").  If you thought that that sentence clearly
>> implied that the finals were "between easy and difficult", then your
>> writing skills stink.
>
> My writing skills are not in question here, however your reading and
> comprehension skills should be. How could you possibly know for sure,
> beyond any reasonable doubt, that the writer was suggesting the final
> exam was "easy"? In fact, the writer never even mentioned the word
> "easy" at all! The writer only stated that the test was NOT
> *difficult*. How does "not difficult" extrapolate to "easy".

That may be the literal meaning, but English composition does not
always follow the rules of predicate logic.  To me, the emphatic use
of "to my surprise" in the construction "I expected X, but to my
surprise I found it was not" implies not merely the literal "not X"
but actually the opposite of X; and the opposite of "difficult" is
"easy".

Feel free to call my reading comprehension skills into question all
you like, but remember that it is the writer, not the reader, who
chooses the words he uses to convey his ideas, and so it is a poor
writer indeed who blames his audience for a failure to communicate.

>> > Listen, you try to make an argument that "pretty" somehow quantifies
>> > the "difficulty of an easy task". Okay, if "pretty" is a quantifier,
>> > then what EXACTLY is it's quantity, exactly? You see, you've gained
>> > nothing by using "pretty".
>>
>> It is a qualifier, not a quantifier,
>
> Oh i see, NOW it's a qualifier!

I don't recall ever saying otherwise.

> So what is "easy" qualified for?
>
>  1. A zero interest loan?
>  2. A sweepstakes?
>
> or maybe you meant "qualified as"
>
>  1. a traffic cop?
>  2. a clumsy ship captain?
>
> or maybe you meant "has authority to qualify",

Or more likely I meant:

2.
Grammar .
b. an adverb that modifies adjectives or other adverbs and typically
expresses degree or intensity, as very, somewhat,  or quite.

(dictionary.com)

But I think that you knew that and are being deliberately obtuse as a
means of evasion.

> *[Thought Exercise]*
> Take a word like "applause". Let's say we want to quantify the level
> of applause to some variable degree of precision. We could say:
> "roaring applause", even though the base definition of "roaring" is a
> sound an animal creates. You see "roaring" can make the transformation
> whilst "pretty" cannot. Why? Because the base definition of roaring
> refers to "magnitude of sound". In that sense, an applause can roar.
> But the applause can never be "pretty loud" because pretty is 1) not a
> quantifier 2) cannot make the transformation to quantify sound.
> "Pretty" is not a quantifier, it's an observation, or an opinion if
> you like.

I will agree that "roaring applause", while a bit cliche, is more
expressive than "pretty loud applause".  That does not invalidate
"pretty loud applause" as a meaningful phrase, any more than it
invalidates "very loud applause" or "slightly loud applause".  I'm not
interested in continuing a pointless back-and-forth over whether
"pretty" is a real adverb, though, so I'll leave it at that.

[toc] | [prev] | [next] | [standalone]

#19467

On Jan 25, 8:02 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Wed, Jan 25, 2012 at 6:00 PM, Rick Johnson
> <rantingrickjohn...@gmail.com> wrote:
> > On Jan 25, 6:20 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> >> On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson

> > My writing skills are not in question here, however your reading and
> > comprehension skills should be. How could you possibly know for sure,
> > beyond any reasonable doubt, that the writer was suggesting the final
> > exam was "easy"? In fact, the writer never even mentioned the word
> > "easy" at all! The writer only stated that the test was NOT
> > *difficult*. How does "not difficult" extrapolate to "easy".
>
> That may be the literal meaning, but English composition does not
> always follow the rules of predicate logic.  To me, the emphatic use
> of "to my surprise" in the construction "I expected X, but to my
> surprise I found it was not" implies not merely the literal "not X"
> but actually the opposite of X; and the opposite of "difficult" is
> "easy".

I am not arguing that the exam was not easy, maybe it was easy, i
dunno? But from the lack of detail given, we can never be absolutely
sure. The possible subjective "range of difficulty" lies somewhere
between easy and anything up to, BUT NOT INCLUDING, difficult. In that
sense the exam could have been easy, slightly easy, moderately easy,
or slightly difficult. Difficulty and difficult are not
interchangeable. Anyway, the point is we can never be sure of the
precision in this case, and using "pretty" offers the same level of
ambiguity as not using a quantifier -- even though pretty IS NOT a
quantifier :-). That is the connection i wanted you to understand.

> > *[Thought Exercise]*
> > Take a word like "applause". Let's say we want to quantify the level
> > of applause to some variable degree of precision. We could say:
> > "roaring applause", even though the base definition of "roaring" is a
> > sound an animal creates. You see "roaring" can make the transformation
> > whilst "pretty" cannot. Why? Because the base definition of roaring
> > refers to "magnitude of sound". In that sense, an applause can roar.
> > But the applause can never be "pretty loud" because pretty is 1) not a
> > quantifier 2) cannot make the transformation to quantify sound.
> > "Pretty" is not a quantifier, it's an observation, or an opinion if
> > you like.
>
> I will agree that "roaring applause", while a bit cliche, is more
> expressive than "pretty loud applause".

The phrase is not just more expressive, "roaring" IS a legit
"quantifier", with the power to inject magnitude and make the
transformation all WITHOUT perverting its base definition.

> That does not invalidate
> "pretty loud applause" as a meaningful phrase, any more than it
> invalidates "very loud applause" or "slightly loud applause".  I'm not
> interested in continuing a pointless back-and-forth over whether
> "pretty" is a real adverb, though, so I'll leave it at that.

I believe we'll just have to "agree to disagree" on the issue of
pretty. However, let's take a step back and view this issue from a
global perspective. Ask yourself:

Q: "Am i choosing my words carefully, or just blindly imitating others
to the detriment of my own thought patterns"?

[toc] | [prev] | [next] | [standalone]

#19470

On Thu, Jan 26, 2012 at 2:01 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I believe we'll just have to "agree to disagree" on the issue of
> pretty. However, let's take a step back and view this issue from a
> global perspective. Ask yourself:
>
> Q: "Am i choosing my words carefully, or just blindly imitating others
> to the detriment of my own thought patterns"?

I'm choosing my words carefully:

Rick, you are a troll, and at the moment, you are being eclipsed in
intelligence by 88888.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web