Re: Noob question: Is all this typecasting normal?
[following up late] In article 2b3c916e-6908-4b12-933f-8f7bfa86c...@i20g2000prf.googlegroups.com, Russ P. russ.paie...@gmail.com wrote: Fair enough, but for code that is not intended for general public usage (i.e., most code) so-called camelCase is every bit as good if not better than using underscores to divide variable names. It saves a few characters, and in my opinion it's significantly easier to read. Identifiers divided by underscores always appear to me at first glance to be multiple words, and I find that very annoying. So unless you think the standard library will someday include code for air traffic management, I'll stick with camelCase, and I'll thank you for not making an issue of it. You are missing the point: suppose you write a useful library in your air traffic management application, maybe one that does a good job of handling user input. If you have done a proper job of abstracting it from your application as a whole, you could easily publicize it, but it will never get into the standard library unless it meets current PEP8 guidelines. Why fuss about trying to figure out which parts of your application might in the future be published? -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Sat, 17 Jan 2009 06:09:29 -0800, Aahz wrote: You are missing the point: suppose you write a useful library in your air traffic management application, maybe one that does a good job of handling user input. If you have done a proper job of abstracting it from your application as a whole, you could easily publicize it, but it will never get into the standard library unless it meets current PEP8 guidelines. Why fuss about trying to figure out which parts of your application might in the future be published? You know, it is quite possible that some people may not care whether or not their code ends up in the standard library. Holding out the possibility of inclusion in the std lib may not be quite the encouragement you expect :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
2009/1/3 Russ P. russ.paie...@gmail.com: So unless you think the standard library will someday include code for air traffic management, I'll stick with camelCase, and I'll thank you for not making an issue of it. Another late comment, sorry, but as an air traffic management safety consultant, I'm quite interested about where in ATM you plan to use Python code, and how you will be meeting the applicable safety standards in the relevant administration. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
Anyone have something to say about the userio stuff?
(If you're going to post something about my coding style, I invite you
to do something infinitely more useful:
write crapToPep8.py {or is it crap_to_pep8?} to satisfy your sick
fetish for consistency.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
Gabriel Genellina gagsl-...@yahoo.com.ar writes:
En Mon, 05 Jan 2009 02:03:26 -0200, Roy Smith r...@panix.com escribió:
The other day, I came upon this gem. It's a bit of perl embedded in a
Makefile; this makes it even more gnarly because all the $'s get
doubled to
hide them from make:
define absmondir
$(shell perl -e ' \
sub absmon { my $$a = $$_[0]; \
if ( $$^O =~ m/cygwin|MSWin32/i ) {
$$prefix = `/bin/mount -p|awk NR==2{print
\\\$$1}`;
chomp($$prefix); \
$$a = ($$_[1]||$(PWD)) . /$$a \
unless ( $$a =~ m !^(:?$$prefix|/|[A-Za-z]:)! ); \
} else { $$a = ($$_[1]||$(PWD)) . /$$a unless ( $$a =~ m !^/!
); } \
return unslash(undot(undotdot($$a))); }; \
sub unslash ($$) { $$_[0] =~ s://+:/:g; $$_[0] =~ s:/$$::;
return($$_[0]);
}; \
sub undot ($$) { $$_[0]=~s:/\./:/:g; return ($$_[0]); }; \
sub undotdot ($$) { my $$in = $$_[0]; \
return ( $$in =~ s:/[^/.][^/]*/\.\.::g )?undotdot($$in):$$in; }; \
print absmon($(1),$(2)); \
' )
endef
Barf-o-rama. I know what it's supposed to do, and I still can't
figure it out.
Ouch! Me too, when I come to some piece of Perl code I've written some
years ago, I invariably think what's all this noise?. Never happens
with other languages I've used in the past.
I still occassion upon the chance to write some Perl, and even as a
full-time developer who works with Python for a living, I relish every
opportunity.
The funny thing is that I've never had the problem of writing code like
this in Perl. The example is a very poor use-case and doesn't reflect on
the useful/useless-ness of the language itself but more on the choices
of the implementor.
Perl is a very useful language overall and when used properly, very
powerful.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
En Mon, 05 Jan 2009 02:03:26 -0200, Roy Smith r...@panix.com escribió:
The other day, I came upon this gem. It's a bit of perl embedded in a
Makefile; this makes it even more gnarly because all the $'s get doubled
to
hide them from make:
define absmondir
$(shell perl -e ' \
sub absmon { my $$a = $$_[0]; \
if ( $$^O =~ m/cygwin|MSWin32/i ) {
$$prefix = `/bin/mount -p|awk NR==2{print \\\$$1}`;
chomp($$prefix); \
$$a = ($$_[1]||$(PWD)) . /$$a \
unless ( $$a =~ m !^(:?$$prefix|/|[A-Za-z]:)! ); \
} else { $$a = ($$_[1]||$(PWD)) . /$$a unless ( $$a =~ m !^/! );
} \
return unslash(undot(undotdot($$a))); }; \
sub unslash ($$) { $$_[0] =~ s://+:/:g; $$_[0] =~ s:/$$::;
return($$_[0]);
}; \
sub undot ($$) { $$_[0]=~s:/\./:/:g; return ($$_[0]); }; \
sub undotdot ($$) { my $$in = $$_[0]; \
return ( $$in =~ s:/[^/.][^/]*/\.\.::g )?undotdot($$in):$$in; }; \
print absmon($(1),$(2)); \
' )
endef
Barf-o-rama. I know what it's supposed to do, and I still can't figure
it out.
Ouch! Me too, when I come to some piece of Perl code I've written some
years ago, I invariably think what's all this noise?. Never happens with
other languages I've used in the past.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
My gmail did that. FYI, it wasn't intentional. А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я Paula Poundstone - I don't have a bank account because I don't know my mother's maiden name. On Sun, Jan 4, 2009 at 1:41 AM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sat, 03 Jan 2009 16:19:58 +0100, Bruno Desthuilliers wrote: But indeed, you obviously cannot add strings with numerics nor concatenate numerics with strings. This would make no sense. The OP comes from a Perl background, which AFAIK allows you to concat numbers to strings and add strings to numbers. That's probably the (mis) feature he was hoping Python had. -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 3, 6:41 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: The OP comes from a Perl background, which AFAIK allows you to concat numbers to strings and add strings to numbers. That's probably the (mis) feature he was hoping Python had. That's correct -- and that's been one of the more difficult parts of my transition. Learned C++ in college, spent a few years doing Perl, and now all of a sudden type matters again. It's a very different philosophy, but I'm determined to stick with it until I have an Aha! moment and find something I can do more easily than I can with Perl. -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
In article
cc87ebf5-5ce1-4fb5-bb2d-cd4bc2426...@q36g2000vbn.googlegroups.com,
sprad jsp...@gmail.com wrote:
On Jan 3, 6:41 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
The OP comes from a Perl background, which AFAIK allows you to concat
numbers to strings and add strings to numbers. That's probably the (mis)
feature he was hoping Python had.
That's correct -- and that's been one of the more difficult parts of
my transition. Learned C++ in college, spent a few years doing Perl,
and now all of a sudden type matters again. It's a very different
philosophy, but I'm determined to stick with it until I have an Aha!
moment and find something I can do more easily than I can with Perl.
The Aha! moment comes 6 months from now, when you discover that you can
understand the Python code you wrote 6 months ago, but the Perl code you
wrote at the same time has become gibberish, even to you.
The other day, I came upon this gem. It's a bit of perl embedded in a
Makefile; this makes it even more gnarly because all the $'s get doubled to
hide them from make:
define absmondir
$(shell perl -e ' \
sub absmon { my $$a = $$_[0]; \
if ( $$^O =~ m/cygwin|MSWin32/i ) {
$$prefix = `/bin/mount -p|awk NR==2{print \\\$$1}`;
chomp($$prefix); \
$$a = ($$_[1]||$(PWD)) . /$$a \
unless ( $$a =~ m !^(:?$$prefix|/|[A-Za-z]:)! ); \
} else { $$a = ($$_[1]||$(PWD)) . /$$a unless ( $$a =~ m !^/! ); } \
return unslash(undot(undotdot($$a))); }; \
sub unslash ($$) { $$_[0] =~ s://+:/:g; $$_[0] =~ s:/$$::; return($$_[0]);
}; \
sub undot ($$) { $$_[0]=~s:/\./:/:g; return ($$_[0]); }; \
sub undotdot ($$) { my $$in = $$_[0]; \
return ( $$in =~ s:/[^/.][^/]*/\.\.::g )?undotdot($$in):$$in; }; \
print absmon($(1),$(2)); \
' )
endef
Barf-o-rama. I know what it's supposed to do, and I still can't figure it
out.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Mon, Jan 5, 2009 at 1:47 PM, sprad jsp...@gmail.com wrote: On Jan 3, 6:41 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: The OP comes from a Perl background, which AFAIK allows you to concat numbers to strings and add strings to numbers. That's probably the (mis) feature he was hoping Python had. I guess perl must have coercing for it's built-in types ? :) *shrugs* To be honest, doing such operations doesn't make much sense to me ... It's difficult to correctly understand what the following expression should evaluate to: a = 2 b = 3 c = foo a + b + c Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for +: 'int' and 'str' %d %d %s % (a, b, c) '2 3 foo' That's correct -- and that's been one of the more difficult parts of my transition. Learned C++ in college, spent a few years doing Perl, and now all of a sudden type matters again. It's a very different philosophy, but I'm determined to stick with it until I have an Aha! moment and find something I can do more easily than I can with Perl. As mentioned string formatting is your friend :) cheers James -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
sprad a écrit : I've done a good bit of Perl, but I'm new to Python. I find myself doing a lot of typecasting (or whatever this thing I'm about to show you is called), Actually, it's just plain object instanciation. and I'm wondering if it's normal, or if I'm missing an important idiom. For example: bet = raw_input(Enter your bet) if int(bet) == 0: # respond to a zero bet raw_input() returns a string. If you want an int and the string is supposed to contain a legitimate string representation of an integer, then yes, passing the string to the int object constructor is the right thing to do. I'd just write it a bit diffently: bet = int(raw_input(Enter your bet)) if bet == 0: # code here or even better: def read_int(prompt, err=Sorry, '%s' is not a valid integer): while True: answer = raw_input(prompt) try: return int(answer) except ValueError: print err % answer bet = read_int(Enter your bet) if bet == 0: # code here Or later, I'll have an integer, and I end up doing something like this: print You still have $ + str(money) + remaining May suggest learning about string formatting ? print You still have $%s remaining % money But indeed, you obviously cannot add strings with numerics nor concatenate numerics with strings. This would make no sense. All the time, I'm going int(this) and str(that). Am I supposed to? Depends on the context. -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 2, 10:50 pm, Ben Finney bignose+hates-s...@benfinney.id.au wrote: s0s...@gmail.com writes: On Jan 2, 7:20 pm, Ben Finney bignose+hates-s...@benfinney.id.au wrote: They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. If it's something to be included in the standard library, I agree (just for consistency, not because using_underscores is better). But for user code, I prefer mixedCase. That seems superficially like an easy distinction. Indeed, PEP 8 explicitly is meant to apply only to code intended for inclusion in the Python standard library. But consider: Python libraries generally don't get into the standard library until they've had a history of widespread public use as an external library. This helps ensure many of the harder-to-find wrinkles get discovered through wide exposure and ironed out before becoming standard. Code bases, especially library interfaces, that get a lot of use across wide communities are naturally going to have a whole lot of other people's code directly using those interfaces. Interfaces that are so widely used garner a high resistance to change, especially for something as non-functional as a naming convention. Choosing the naming convention for one's code is much easier to do when its usage base is smaller than when that base is larger. Therefore the easiest time to choose when to code in conformance to PEP 8 is right at the start. The best conclusion I can come to from this? Unless you explicitly *never* intend sharing your code with *anyone*, it's best to code all your Python code in accordance with PEP 8 anyway. You then don't have to make the decision about whether this is the time to follow PEP 8 or not; just do it by default, and you avoid the needless pain on those occasions, often unforeseeable at the start, where your code later ends up widely used. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__) ‘us’.” —Douglas Adams | Ben Finney Fair enough, but for code that is not intended for general public usage (i.e., most code) so-called camelCase is every bit as good if not better than using underscores to divide variable names. It saves a few characters, and in my opinion it's significantly easier to read. Identifiers divided by underscores always appear to me at first glance to be multiple words, and I find that very annoying. So unless you think the standard library will someday include code for air traffic management, I'll stick with camelCase, and I'll thank you for not making an issue of it. As far as I am concerned, this is one of the most important bits of advice in PEP 8: A Foolish Consistency is the Hobgoblin of Little Minds -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
for each his own. Any more word on userio? On Sat, Jan 3, 2009 at 6:14 PM, Russ P. russ.paie...@gmail.com wrote: On Jan 2, 10:50 pm, Ben Finney bignose+hates-s...@benfinney.id.aubignose%2bhates-s...@benfinney.id.au wrote: s0s...@gmail.com writes: On Jan 2, 7:20 pm, Ben Finney bignose+hates-s...@benfinney.id.aubignose%2bhates-s...@benfinney.id.au wrote: They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. If it's something to be included in the standard library, I agree (just for consistency, not because using_underscores is better). But for user code, I prefer mixedCase. That seems superficially like an easy distinction. Indeed, PEP 8 explicitly is meant to apply only to code intended for inclusion in the Python standard library. But consider: Python libraries generally don't get into the standard library until they've had a history of widespread public use as an external library. This helps ensure many of the harder-to-find wrinkles get discovered through wide exposure and ironed out before becoming standard. Code bases, especially library interfaces, that get a lot of use across wide communities are naturally going to have a whole lot of other people's code directly using those interfaces. Interfaces that are so widely used garner a high resistance to change, especially for something as non-functional as a naming convention. Choosing the naming convention for one's code is much easier to do when its usage base is smaller than when that base is larger. Therefore the easiest time to choose when to code in conformance to PEP 8 is right at the start. The best conclusion I can come to from this? Unless you explicitly *never* intend sharing your code with *anyone*, it's best to code all your Python code in accordance with PEP 8 anyway. You then don't have to make the decision about whether this is the time to follow PEP 8 or not; just do it by default, and you avoid the needless pain on those occasions, often unforeseeable at the start, where your code later ends up widely used. -- \ One of the most important things you learn from the internet | `\ is that there is no 'them' out there. It's just an awful lot of | _o__)'us'. —Douglas Adams | Ben Finney Fair enough, but for code that is not intended for general public usage (i.e., most code) so-called camelCase is every bit as good if not better than using underscores to divide variable names. It saves a few characters, and in my opinion it's significantly easier to read. Identifiers divided by underscores always appear to me at first glance to be multiple words, and I find that very annoying. So unless you think the standard library will someday include code for air traffic management, I'll stick with camelCase, and I'll thank you for not making an issue of it. As far as I am concerned, this is one of the most important bits of advice in PEP 8: A Foolish Consistency is the Hobgoblin of Little Minds -- http://mail.python.org/mailman/listinfo/python-list -- А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
Any more word on userio? None yet, I'm afraid. Should've started a different thread for it - but it's stuck here (in obscurity) forever xd. -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Sat, 03 Jan 2009 20:35:25 +, alex goretoy wrote: for each his own. Please don't top-post. Please don't quote the ENTIRE body of text (PLUS doubling it by including a completely useless HTML version) just to add a trivial comment. Trim the text you are replying to. Any more word on userio? I doubt many people care about it. Why don't you write it, put it up on the Cheeseshop, and see if anyone uses it? Just because you think it is useful doesn't mean others do, but if they do, then great. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Sat, 03 Jan 2009 16:19:58 +0100, Bruno Desthuilliers wrote: But indeed, you obviously cannot add strings with numerics nor concatenate numerics with strings. This would make no sense. The OP comes from a Perl background, which AFAIK allows you to concat numbers to strings and add strings to numbers. That's probably the (mis) feature he was hoping Python had. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Fri, Jan 2, 2009 at 4:15 PM, sprad jsp...@gmail.com wrote: I've done a good bit of Perl, but I'm new to Python. I find myself doing a lot of typecasting (or whatever this thing I'm about to show you is called), and I'm wondering if it's normal, or if I'm missing an important idiom. For example: bet = raw_input(Enter your bet) if int(bet) == 0: # respond to a zero bet Or later, I'll have an integer, and I end up doing something like this: print You still have $ + str(money) + remaining All the time, I'm going int(this) and str(that). Am I supposed to? The cast to the int is needed. The cast to a string isn't. Use string formatting instead. As an added bonus, you can ensure that you always show 2 digits past the decimal. money = 2.1 print You still have $%0.2f remaining % money You still have $2.10 remaining -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
sprad schrieb: I've done a good bit of Perl, but I'm new to Python. I find myself doing a lot of typecasting (or whatever this thing I'm about to show you is called), and I'm wondering if it's normal, or if I'm missing an important idiom. It is normal, although below you make things needlessly complicated. Python is strongly typed, which is a good thing. It refuses to guess you mean when you multiply a string with a number. Or how a number is to be formatted when printed. For example: bet = raw_input(Enter your bet) if int(bet) == 0: # respond to a zero bet You might better do bet = int(raw_input(Enter your bet)) because then you don't need to later on convert bet again and again. But *one* conversion you need. Or later, I'll have an integer, and I end up doing something like this: print You still have $ + str(money) + remaining This is more concisely with much better control over the output-format (think e.g. digits of a fraction) using string-interpolation. See http://docs.python.org/library/stdtypes.html#string-formatting-operations for an overview. In your case, a simple print You still have $%i remaining % bet does the trick. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
You can use the built-in string formatting options and operations. 2.5: http://www.python.org/doc/2.5.2/lib/typesseq-strings.html 2.6: http://docs.python.org/library/string.html In essence, you can do: print You still have $%i remaining %(money) On Jan 2, 2:15 pm, sprad jsp...@gmail.com wrote: I've done a good bit of Perl, but I'm new to Python. I find myself doing a lot of typecasting (or whatever this thing I'm about to show you is called), and I'm wondering if it's normal, or if I'm missing an important idiom. For example: bet = raw_input(Enter your bet) if int(bet) == 0: # respond to a zero bet Or later, I'll have an integer, and I end up doing something like this: print You still have $ + str(money) + remaining All the time, I'm going int(this) and str(that). Am I supposed to? -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
You might better do bet = int(raw_input(Enter your bet)) because then you don't need to later on convert bet again and again. This is all fine until you give it to an end-user. This is what I picture: $ ./script.py Enter your bet: $10 .. or perhaps ten, all, or a jillion other tainted inputs. Python will try to cast these strings, but will slap you with a ValueError instead (an error of some sort, at least). There needs to be a user_io or sanitize module in the standard library to take care of this stuff. Like: import userio logic = userio.userio() number = logic.getNumeric(blah: ) # will offer the user a re-do in case of bad input number = logic.forceGetNumeric(Enter your bet!: ) # even if input is tainted, will return some number text = logic.getText(blargh: ) # return all text text = logic.setValidText([A-Za-z]) text = logic.forceGetText(blargh: ) # return some text, strips invalid chars ... but there isn't, as far as I know. -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Fri, 2 Jan 2009 14:36:04 -0800 (PST) vk vmi...@gmail.com wrote: There needs to be a user_io or sanitize module in the standard library to take care of this stuff. [snip example] Great idea! +1 ... but there isn't, as far as I know. Well, get to it, then. ;) /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
There needs to be a user_io or sanitize module in the standard library to take care of this stuff. [snip] +1 You are sooo right. You know, it is easy to forget about such things after you learn a language, i have written my own input logic, but i remember my __init__ days with python now and the learning curve. Every new user will makes much use of raw_input()[or input 3.0] and has to climb this same little hill every time, you and i do it as second nature. A small module like you describe would be a great addition to the standard library, and heck, i would even use it :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
vk vmi...@gmail.com writes: There needs to be a user_io or sanitize module in the standard library to take care of this stuff. Like: import userio logic = userio.userio() number = logic.getNumeric(blah: ) # will offer the user a re-do in case of bad input number = logic.forceGetNumeric(Enter your bet!: ) # even if input is tainted, will return some number text = logic.getText(blargh: ) # return all text text = logic.setValidText([A-Za-z]) text = logic.forceGetText(blargh: ) # return some text, strips invalid chars ... but there isn't, as far as I know. If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) -- \ “The face of a child can say it all, especially the mouth part | `\of the face.” —Jack Handey | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. atm, I've got a chem final to study for. I'll probably post something resembling useful code tomorrow morning. until then, int(input()) away! -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Fri, 2 Jan 2009 16:16:10 -0800 (PST) vk vmi...@gmail.com wrote: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. FYI: The names themselves aren't he problem at all. They just should be all_lowercase_with_underscores if they're functions or variables. CamelCase (with initial capital!) is reserved for classnames only. /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 2, 6:26 pm, Andreas Waldenburger geekm...@usenot.de wrote: On Fri, 2 Jan 2009 16:16:10 -0800 (PST) vk vmi...@gmail.com wrote: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. FYI: The names themselves aren't he problem at all. They just should be all_lowercase_with_underscores if they're functions or variables. CamelCase (with initial capital!) is reserved for classnames only. /W -- My real email address is constructed by swapping the domain with the recipient (local part). FYI camelCase with __init__ capital is called title case try this: 'hello world.title() -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Fri, 2 Jan 2009 16:44:11 -0800 (PST) r rt8...@gmail.com wrote: On Jan 2, 6:26 pm, Andreas Waldenburger geekm...@usenot.de wrote: On Fri, 2 Jan 2009 16:16:10 -0800 (PST) vk vmi...@gmail.com wrote: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. FYI: The names themselves aren't he problem at all. They just should be all_lowercase_with_underscores if they're functions or variables. CamelCase (with initial capital!) is reserved for classnames only. /W -- My real email address is constructed by swapping the domain with the recipient (local part). FYI camelCase with __init__ capital is called title case try this: OK, since we're smartassing anyway: CamelCase refers specifically to compound words or phrases that are conjoined, that is, written without spaces between the words, where words are separated by writing their respective first letters in capitals. Title case however refers to normal phrases where (space separated) words are capitalized, and no inner capitals occur (unless of course actual CamelCase words are used in the phrase). You even assumed that distinction in your example: 'hello world.title() /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 3, 11:16 am, vk vmi...@gmail.com wrote: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. atm, I've got a chem final to study for. I'll probably post something resembling useful code tomorrow morning. until then, int(input()) away! Building on the earlier example (entering the amount of money for a bet), consider the following possibilities: 10 $10 USD 10.00 USD 10,00 # many European locales 1 # moving to the high rollers table 10,000 10.000 # European 10T # T - thousand dates: 1/12/35 # 1 December or 12 January? What year? 2035? Perhaps not, if the prompt was 'Enter pensioner's date of birth - '. etc etc ... IOW consider not biting off more than you can chew. Also consider that raw_input is not sufficiently frequently used in real-world applications to warrant a data validation library to be built on top of it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
vk vmi...@gmail.com writes: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__)‘us’.” —Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
Ben Finney wrote: vk vmi...@gmail.com writes: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. They don't *need* to do that. It's just a good habit to get into if you plan to write code that gets read and possibly modified by other people. If you write a function called doSomething the PSU won't %...@#%:,,.. carrier lost -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 2, 7:20 pm, Ben Finney bignose+hates-s...@benfinney.id.au wrote: vk vmi...@gmail.com writes: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. If it's something to be included in the standard library, I agree (just for consistency, not because using_underscores is better). But for user code, I prefer mixedCase. +1 for mixedCase! Sebastian -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 2, 6:57 pm, Andreas Waldenburger geekm...@usenot.de wrote:
[snip]
You even assumed that distinction in your example:
'hello world.title()
[snip]
sorry, here is TitleCase.py_b2
py 'hello world'.title().replace(' ', '')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Fri, 02 Jan 2009 21:02:19 -0500, Steve Holden wrote: Ben Finney wrote: vk vmi...@gmail.com writes: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. They don't *need* to do that. They do if you want it accepted into the standard library, which was the hope. Not *my* hope, you understand, but that of the person who suggested it :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
On Jan 2, 6:15 pm, s0s...@gmail.com wrote: On Jan 2, 7:20 pm, Ben Finney bignose+hates-s...@benfinney.id.au wrote: vk vmi...@gmail.com writes: If there were, I would expect it to conform with PEP 8 (get those ugly camelCase names outta there :-) haha, please forgive me. I'll try and think of some more creative names. They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. If it's something to be included in the standard library, I agree (just for consistency, not because using_underscores is better). But for user code, I prefer mixedCase. +1 for mixedCase! Sebastian I agree. I find underscores in variable names to be both ugly and harder to read. At first glance, the underscores are easy to miss. -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
etc etc ... IOW consider not biting off more than you can chew. It's possible that I am, but where's the fun without the risk? Good thinking in your post though! I will add get_date at some point, and I've modified get_numeric already. All-right, the moment you've all been waiting for: - http://docs.google.com/View?docid=dgsp7w2t_2gwf447g8 - Provides: 1) user_io.user_io -- get_text(msg) -- filter_get(msg, valid_chars) -- get_numeric(msg) -- bully_numeric(msg) 2) user_io.progress_bar -- ping() -- stop() Read the doc-strings for details. I know it isn't perfect, so just yell at me on this thread if you don't like something and I'll try to fix it. Actually, I'd rather you fix it yourself and THEN yell at me to update the module. have fun! -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
s0s...@gmail.com writes: On Jan 2, 7:20 pm, Ben Finney bignose+hates-s...@benfinney.id.au wrote: They don't need to be creative; they merely need to conform with the naming scheme as laid out in the PEP. If it's something to be included in the standard library, I agree (just for consistency, not because using_underscores is better). But for user code, I prefer mixedCase. That seems superficially like an easy distinction. Indeed, PEP 8 explicitly is meant to apply only to code intended for inclusion in the Python standard library. But consider: Python libraries generally don't get into the standard library until they've had a history of widespread public use as an external library. This helps ensure many of the harder-to-find wrinkles get discovered through wide exposure and ironed out before becoming standard. Code bases, especially library interfaces, that get a lot of use across wide communities are naturally going to have a whole lot of other people's code directly using those interfaces. Interfaces that are so widely used garner a high resistance to change, especially for something as non-functional as a naming convention. Choosing the naming convention for one's code is much easier to do when its usage base is smaller than when that base is larger. Therefore the easiest time to choose when to code in conformance to PEP 8 is right at the start. The best conclusion I can come to from this? Unless you explicitly *never* intend sharing your code with *anyone*, it's best to code all your Python code in accordance with PEP 8 anyway. You then don't have to make the decision about whether this is the time to follow PEP 8 or not; just do it by default, and you avoid the needless pain on those occasions, often unforeseeable at the start, where your code later ends up widely used. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__)‘us’.” —Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question: Is all this typecasting normal?
Unless you explicitly *never* intend sharing your code with *anyone*, it's best to code all your Python code in accordance with PEP 8 anyway. Well said. Let's bury the puppy already. Anyone have something to say about the userio stuff? -- http://mail.python.org/mailman/listinfo/python-list
