On 11/11/2013 06:05 PM, Dennis Lee Bieber wrote:
On Mon, 11 Nov 2013 09:01:07 -0500, Roy Smith declaimed the
following:
"Ugh, what's this close paren? Does it terminate the get(), or the
print()? I need to go back and count open parens to make sure"
No... You need to use an editor
On 11 November 2013 22:21, Chris Angelico wrote:
> On Tue, Nov 12, 2013 at 7:50 AM, Joshua Landau wrote:
>> The obvious way to me is a binary search:
>
> Which makes an O(log n) search where I have an O(1) lookup. The
> startup cost of denormalization doesn't scale, so when the server
> keeps run
On Mon, Nov 11, 2013 at 3:32 AM, Chris Angelico wrote:
> On Mon, Nov 11, 2013 at 10:17 PM, Steven D'Aprano
> wrote:
>> On Mon, 11 Nov 2013 21:39:27 +1100, Chris Angelico wrote:
>>> denormalizes it into a lookup table by creating 70 entries quoting the
>>> first string, 15 quoting the second, 5, a
On Tue, Nov 12, 2013 at 7:50 AM, Joshua Landau wrote:
> The obvious way to me is a binary search:
Which makes an O(log n) search where I have an O(1) lookup. The
startup cost of denormalization doesn't scale, so when the server
keeps running for two years or more, it's definitely worth processing
On 11 November 2013 10:39, Chris Angelico wrote:
> On Mon, Nov 11, 2013 at 9:09 PM, wrote:
>> Regarding the "select" statement, I think the most "Pythonic" approach is
>> using dictionaries rather than nested ifs.
>> Supposing we want to decode abbreviated day names ("mon") to full names
>> ("
On Sunday, November 10, 2013 4:56:38 PM UTC+8, Jorgen Grahn wrote:
> On Sun, 2013-11-10, Chris Angelico wrote:
>
> > On Sun, Nov 10, 2013 at 11:41 AM, Roy Smith wrote:
>
> >> On 09/11/2013 22:58, Chris Angelico wrote:
>
> >>> >
>
> >>> > * Some languages are just fundamentally bad. I do not re
On 11/11/2013 01:28 AM, wxjmfa...@gmail.com wrote:
* Some languages are just fundamentally bad.
The flexible string representation is a perfect exemple.
Argh! He escaped! *chase* *scuffle* *stuff* *stuff* *stuff*
Whew. Safely back in the troll bin.
Okay, back to my day.
--
~Ethan~
--
> On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote:
> The C switch statement is very limited. The select statement
> in the dialect of BASIC I regularly use is more flexible.
> It's more concise on long if chains because it elides the "end
> if"s. But the use of indentation for
On Monday, November 11, 2013 7:31:07 PM UTC+5:30, Roy Smith wrote:
> > On Saturday, November 9, 2013 10:30:26 AM UTC-6, rusi wrote:
> > > print ( {"mon":"mondays suck",
> > > "tue":"at least it's not monday",
> > > "wed":"humpday"
> > > }.get(day_of_week,"its some other d
On 11/11/2013 09:28, wxjmfa...@gmail.com wrote:
* Some languages are just fundamentally bad.
The flexible string representation is a perfect exemple.
Again, a short explanation:
This FSR splits unicode in chunks. Two immediate consequences:
- It's necessary to keep track of "each individual
> On Saturday, November 9, 2013 10:30:26 AM UTC-6, rusi wrote:
> > print ( {"mon":"mondays suck",
> > "tue":"at least it's not monday",
> > "wed":"humpday"
> > }.get(day_of_week,"its some other day")
> > )
In article <8618d47d-518c-4f35-a879-57fad7525...@googlegrou
On Mon, Nov 11, 2013 at 10:53 PM, Robert Kern wrote:
> Heh. I've done pretty much exactly the same thing to implement an engine[1]
> to draw from the random tables on Abulafia[2] which have nearly the same
> structure. It scales up reasonably well beyond d100s. It's certainly not a
> technique I w
On 2013-11-11 10:39, Chris Angelico wrote:
A 'minor weapon' is based on a roll of a 100-sided dice. If it's 01 to
70, "+1 weapon: 2,000gp [weapon]"; if it's 71 to 85, "+2 weapon:
8,000gp [weapon]"; if 86 to 90, "Specific weapon [minor specific
weapon]"; and if 91 to 100, "Special ability [minor
On Mon, Nov 11, 2013 at 10:17 PM, Steven D'Aprano
wrote:
> On Mon, 11 Nov 2013 21:39:27 +1100, Chris Angelico wrote:
>> denormalizes it into a lookup table by creating 70 entries quoting the
>> first string, 15 quoting the second, 5, and 10, respectively.
>
> Ewww :-(
>
> Imagine having to print o
On Mon, 11 Nov 2013 21:39:27 +1100, Chris Angelico wrote:
> My code to handle that starts out with this array:
>
> "minor weapon":({
> 70,"+1 weapon: 2,000gp [weapon]",
> 85,"+2 weapon: 8,000gp [weapon]",
> 90,"Specific weapon [minor specific weapon]", 100,"Special ability
> [mino
On Mon, Nov 11, 2013 at 9:09 PM, wrote:
> Regarding the "select" statement, I think the most "Pythonic" approach is
> using dictionaries rather than nested ifs.
> Supposing we want to decode abbreviated day names ("mon") to full names
> ("Monday"):
That's an obvious mapping, though. If you're
Regarding the "select" statement, I think the most "Pythonic" approach is using
dictionaries rather than nested ifs.
Supposing we want to decode abbreviated day names ("mon") to full names
("Monday"):
day_abbr='mon'
day_names_mapping={
'mon':'Monday',
'tue':'Tuesday',
'wed':'Wednesd
On Mon, Nov 11, 2013 at 8:28 PM, wrote:
>> * Some languages are just fundamentally bad.
>
> The flexible string representation is a perfect exemple.
Wow. A new low for you, jmf... comparing PEP 393 to Ook?!?
> In fact, with such a mechanism, it is even impossible to write an editor.
And someho
>
>
> * Some languages are just fundamentally bad.
The flexible string representation is a perfect exemple.
Again, a short explanation:
This FSR splits unicode in chunks. Two immediate consequences:
- It's necessary to keep track of "each individual internal pieces of text".
- It's necessary
On Saturday, November 9, 2013 10:30:26 AM UTC-6, rusi wrote:
> [...]
> Well
>
> print ( {"mon":"mondays suck",
> "tue":"at least it's not monday",
> "wed":"humpday"
> }.get(day_of_week,"its some other day")
> )
> may be dense
> Separate into named dictionary and its
On 11/10/2013 6:29 PM, Chris Angelico wrote:
On Mon, Nov 11, 2013 at 4:12 AM, Dennis Lee Bieber
wrote:
-123 .bit_length()
-7
No parens needed if a space precedes the .
Heh! I would call that an inferior alternative to the parentheses
though; it's so unusual to put a space before th
On Mon, Nov 11, 2013 at 4:12 AM, Dennis Lee Bieber
wrote:
-123 .bit_length()
> -7
>
> No parens needed if a space precedes the .
Heh! I would call that an inferior alternative to the parentheses
though; it's so unusual to put a space before the dot that I wouldn't
consider it somethi
Am 09.11.2013 14:27 schrieb Joshua Landau:
`select` is quite an odd statement, in that in most cases it's just a
weaker variant of `if`. By the time you're at the point where a
`select` is actually more readable you're also at the point where a
different control flow is probably a better idea. T
On Sun, Nov 10, 2013 at 10:39 PM, Ian Kelly wrote:
> On Sun, Nov 10, 2013 at 2:22 AM, Chris Angelico wrote:
>> JavaScript has magic around the dot and function-call operators, as I
>> mentioned earlier. Lots of other languages have some little quirk
>> somewhere that breaks this rule; some have a
On Sun, Nov 10, 2013 at 2:22 AM, Chris Angelico wrote:
> JavaScript has magic around the dot and function-call operators, as I
> mentioned earlier. Lots of other languages have some little quirk
> somewhere that breaks this rule; some have a LOT of quirks that break
> this rule. Does Python have a
On Sun, Nov 10, 2013 at 7:47 PM, Jorgen Grahn wrote:
> On Sat, 2013-11-09, Chris Angelico wrote:
>> On Sun, Nov 10, 2013 at 12:08 AM, John von Horn wrote:
> ...
>>> * Why not allow floater=float(int1/int2) - rather than floater=float
>>> (int1)/float(int2)?
>>>
>>> Give me a float (or an error me
On Sun, 2013-11-10, Chris Angelico wrote:
> On Sun, Nov 10, 2013 at 11:41 AM, Roy Smith wrote:
>> On 09/11/2013 22:58, Chris Angelico wrote:
>>> >
>>> > * Some languages are just fundamentally bad. I do not recommend ever
>>> > writing production code in Whitespace, Ook, or Piet.
>>
>> One of the
On Sat, 2013-11-09, Chris Angelico wrote:
> On Sun, Nov 10, 2013 at 12:08 AM, John von Horn wrote:
...
>> * Why not allow floater=float(int1/int2) - rather than floater=float
>> (int1)/float(int2)?
>>
>> Give me a float (or an error message) from evaluating everything in the
>> brackets. Don't mak
On Sat, Nov 9, 2013 at 2:58 PM, Chris Angelico wrote:
> So, on what basis _would_ you choose a language for some purpose?
> Without speaking specifically of web development here, how do you
> choose a language?
Most generally, you choose a language informed by the language
designer's intentions o
On Sun, Nov 10, 2013 at 12:05 PM, Mark Lawrence wrote:
> I'd forgotten I'd used Monk back around 1999/2000. I couldn't remember much
> about it so just looked it up here
> http://docs.oracle.com/cd/E18867_01/SRE/Monk_Reference_SRE.pdf, not sure if
> it's double or triple yuck.
>From the contents
On 09/11/2013 23:24, Mark Lawrence wrote:
On 09/11/2013 22:58, Chris Angelico wrote:
* Some languages are just fundamentally bad. I do not recommend ever
writing production code in Whitespace, Ook, or Piet.
In my last job I was forced into using Apple(42 not so obvious ways to
do it)Script.
On Sun, Nov 10, 2013 at 11:50 AM, MRAB wrote:
> On 09/11/2013 22:44, Jonathan wrote:
>> In pythonic syntax:
>>
>> select :
>>case ,[],:
>>
>>
>>case else:
>>
> [snip]
>
> It's more likely that the cases would be indented the same amount as
> the 'select', and you wouldn't n
On Sun, Nov 10, 2013 at 11:41 AM, Roy Smith wrote:
> On 09/11/2013 22:58, Chris Angelico wrote:
>> >
>> > * Some languages are just fundamentally bad. I do not recommend ever
>> > writing production code in Whitespace, Ook, or Piet.
>
> One of the worst coding experiences I ever had was trying to
On 09/11/2013 22:44, Jonathan wrote:
On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote:
`select` is quite an odd statement, in that in most cases it's just a
weaker variant of `if`. By the time you're at the point where a
`select` is actually more readable you're also at the p
On 09/11/2013 22:58, Chris Angelico wrote:
> >
> > * Some languages are just fundamentally bad. I do not recommend ever
> > writing production code in Whitespace, Ook, or Piet.
One of the worst coding experiences I ever had was trying to build an
app for a Roku media player. They have a home-gro
On Sun, Nov 10, 2013 at 9:44 AM, Jonathan wrote:
> In pythonic syntax:
>
> select :
> case ,[],:
> which is equivalent to: elif = :
> which is equivalent to: elif
Small clarification: It's more akin to assigning to a
temporary, and then comparing that temporary against everything. It's
On 09/11/2013 22:58, Chris Angelico wrote:
* Some languages are just fundamentally bad. I do not recommend ever
writing production code in Whitespace, Ook, or Piet.
In my last job I was forced into using Apple(42 not so obvious ways to
do it)Script. Yuck.
--
Python is the second best prog
On Sun, Nov 10, 2013 at 8:21 AM, Mark Janssen wrote:
>> I'd be interested to hear your thoughts on where the field of computer
>> languages is heading, and how that affects the choice of languages for
>> building web sites.
>
> Well, there aren't that many groupings towards which languages
> spe
On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote:
> `select` is quite an odd statement, in that in most cases it's just a
> weaker variant of `if`. By the time you're at the point where a
> `select` is actually more readable you're also at the point where a
> different control f
> I'd be interested to hear your thoughts on where the field of computer
> languages is heading, and how that affects the choice of languages for
> building web sites.
Well, there aren't that many groupings towards which languages
specialize for (not including embedded or other application-speci
On 2013-11-09 21:01, Mark Lawrence wrote:
> no comma is needed but a comma will be accepted.
I find the optional trailing comma particularly useful (and painful in
languages that don't accept it) for doing inline lists to produce
cleaner version-control diffs. I write most of my code like this
On 09/11/2013 20:33, Mark Janssen wrote:
* Call me pedantic by why do we need a trailing comma for a list of one
item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or
["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.
This one got answered, it has to do with the
On Saturday, November 9, 2013 3:33:30 PM UTC-5, zipher wrote:
> Personally, I wouldn't recommend Python for web scripts. But I'm
> biased and am speaking from where I see the field of computer
> languages heading.
>
> MarkJ
> Tacoma, Washington
I'd be interested to hear your thoughts on where th
A little late, but a couple of cents worth more data:
> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?
This has to do with evaluation order, the stuff inside the parens gets
evaluated fir
On 2013-11-10 01:27, Chris Angelico wrote:
> > Is everyone happy with the way things are? Could anyone recommend
> > a good, high level language for CGI work? Not sure if I'm going
> > to be happy with Perl (ahhh, get him, he's mentioned Perl and is
> > a heretic!) or Python. I would very much valu
On Sat, 09 Nov 2013 07:08:25 -0600, John von Horn wrote:
Thanks so much for the replies. I'll get my head down and keep on going.
Sometimes it's great to be wrong. I have a good feeling about this
language. It's also nice that I can tap into this pool of knowledge that
is comp.lang.python - I'l
On Saturday, November 9, 2013 9:26:02 PM UTC+5:30, Roy Smith wrote:
> In article rusi wrote:
> > On Saturday, November 9, 2013 6:38:25 PM UTC+5:30, John von Horn wrote:
> > > Another useful tool in the programmer's toolbox
> > > Select DayofWeek
> > > case "mon"
> > > ...
> > > end select
> >
In article ,
rusi wrote:
> On Saturday, November 9, 2013 6:38:25 PM UTC+5:30, John von Horn wrote:
> > Another useful tool in the programmer's toolbox
>
> > Select DayofWeek
>
> > case "mon"
>
> > ...
>
> > end select
>
>
> You can typically write this in python as a dictionary
>
On Saturday, November 9, 2013 6:38:25 PM UTC+5:30, John von Horn wrote:
> Another useful tool in the programmer's toolbox
> Select DayofWeek
> case "mon"
> ...
> end select
You can typically write this in python as a dictionary
cases = {"mon": do_mon-action,
"tue", do_t
On Sun, Nov 10, 2013 at 2:25 AM, Steven D'Aprano
wrote:
> On Sun, 10 Nov 2013 01:27:11 +1100, Chris Angelico wrote:
>
>> I was trying to sandbox CPython and run untrusted scripts while stopping
>> them from accessing the OS or file system. It's basically impossible
>
> PyPy is supposed to come wit
On Sun, 10 Nov 2013 01:27:11 +1100, Chris Angelico wrote:
> I was trying to sandbox CPython and run untrusted scripts while stopping
> them from accessing the OS or file system. It's basically impossible
PyPy is supposed to come with a proper sandbox. Although even in that
case, I think it is re
On Sun, Nov 10, 2013 at 12:08 AM, John von Horn wrote:
> Hi Everyone,
>
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.
Hi! For myself, I've come from a background writing
John von Horn writes:
> Hi Everyone,
>
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4)
> and am enjoying working along to some youtube tutorials. I've done a
> little programming in the past.
>
> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not all
On 09/11/2013 13:08, John von Horn wrote:
Hi Everyone,
I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
enjoying working along to some youtube tutorials. I've done a little
programming in the past.
If it's possible I'd strongly recommend Python 3.3, there's lots of
goo
On 9 November 2013 13:08, John von Horn wrote:
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.
>
> I've just got a few thoughts I'd like to share and ask about:
>
> * Why no
On Saturday, November 9, 2013 8:08:25 AM UTC-5, John von Horn wrote:
> Hi Everyone,
>
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.
>
> I've just got a few thoughts I'd
56 matches
Mail list logo