Re: What is the semantics meaning of 'object'?
On Sat, Jun 22, 2013 at 11:23 PM, Steven D'Aprano wrote: > On Sat, 22 Jun 2013 22:27:10 -0600, Ian Kelly wrote: >> I actually consider that an up side. Sure it's inconvenient that you >> can't delegate all such methods at once just by overriding >> __getattribute__, but it would be more troublesome to *accidentally* >> implement such methods because you implemented __getattribute__. > > It's hard to see a case where that would be a bad thing. > > 1) If the proxied object doesn't include __dunder__ methods, then the > proxy will just end up up calling the default object dunder methods, > exactly as if they weren't proxied. > > 2) If the proxied object does include dunders, then you generally want > the proxy to call them, with perhaps one or two exceptions, which need to > be overridden regardless of whether they are dunders or not. Proxying objects is not the only use of __getattribute__. >> And >> then there are methods that really should not be delegated in the first >> place, like __del__. > > If you're using __del__, you're probably doing something wrong :-) > > I suppose that __del__ is a good counter-example, but (1) hardly any > classes use __del__, and (2) for those that do, it's *way* simpler to > manually override __del__ in the proxy than to manually delegate every > dunder method you care about. There are typically a lot of dunder methods > you care about. If you manually override __del__ in the proxy, then as far as the garbage collector is concerned, your proxy object has a __del__ method (even if it does nothing), and so it will be treated differently from an object without a __del__ method. > It is not the case that dunder methods cannot be automatically proxied > because somebody deliberately designed Python to work that way. It's an > accidental side-effect of the way new-style classes resolve method calls, > due to decisions made for other reasons having nothing to do with > delegation. Can you elaborate or provide a link? I'm curious to know what other reason there could be for magic methods to behave differently from normal methods in this regard. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is the semantics meaning of 'object'?
On Sat, 22 Jun 2013 22:27:10 -0600, Ian Kelly wrote: > On Sat, Jun 22, 2013 at 9:20 PM, Steven D'Aprano > wrote: >> * on the down side, automatic delegation of special double-underscore >> methods like __getitem__ and __str__ doesn't work with new-style >> classes. > > I actually consider that an up side. Sure it's inconvenient that you > can't delegate all such methods at once just by overriding > __getattribute__, but it would be more troublesome to *accidentally* > implement such methods because you implemented __getattribute__. It's hard to see a case where that would be a bad thing. 1) If the proxied object doesn't include __dunder__ methods, then the proxy will just end up up calling the default object dunder methods, exactly as if they weren't proxied. 2) If the proxied object does include dunders, then you generally want the proxy to call them, with perhaps one or two exceptions, which need to be overridden regardless of whether they are dunders or not. > And > then there are methods that really should not be delegated in the first > place, like __del__. If you're using __del__, you're probably doing something wrong :-) I suppose that __del__ is a good counter-example, but (1) hardly any classes use __del__, and (2) for those that do, it's *way* simpler to manually override __del__ in the proxy than to manually delegate every dunder method you care about. There are typically a lot of dunder methods you care about. It is not the case that dunder methods cannot be automatically proxied because somebody deliberately designed Python to work that way. It's an accidental side-effect of the way new-style classes resolve method calls, due to decisions made for other reasons having nothing to do with delegation. That this accident just happens to have one tiny silver lining doesn't change the fact that, overall, it's still a dark cloud. In classic classes, automatic delegation was a first-class design pattern. With new-style classes, it's second-class, and that's a pity. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What is the semantics meaning of 'object'?
On Sat, Jun 22, 2013 at 9:20 PM, Steven D'Aprano wrote: > * on the down side, automatic delegation of special double-underscore > methods like __getitem__ and __str__ doesn't work with new-style classes. I actually consider that an up side. Sure it's inconvenient that you can't delegate all such methods at once just by overriding __getattribute__, but it would be more troublesome to *accidentally* implement such methods because you implemented __getattribute__. And then there are methods that really should not be delegated in the first place, like __del__. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 12:58 PM, Steven D'Aprano wrote: > On Sun, 23 Jun 2013 02:20:56 +0100, MRAB wrote: > >> One vs not-one isn't good enough. Some languages use the singular with >> any numbers ending in '1'. Some languages have singular, dual, and >> plural. Etc. It's surprising how inventive people can be! :-) > > This is a good time to link to these interesting articles: > > http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > > http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time Thanks for that! I know the one about names, but have just had a good-fun read of the second one. My sister and I are currently playing Dungeons and Dragons together, and the trek through the bee-infested forest took second place to laughing about time. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 1:22 PM, Steven D'Aprano wrote: > On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote: > >> In article <51c66455$0$2$c3e8da3$54964...@news.astraweb.com>, >> Steven D'Aprano wrote: >> >>> http://infiniteundo.com/post/25326999628/falsehoods-programmers- > believe-about- >>> time >> >> Number 2 on the list is "Months have either 30 or 31 days", which was >> obviously believed by whoever made this sign: http://tinyurl.com/mgv39on > > Can you link directly to the image? Facebook and my browser don't get on. https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-frc1/s720x720/429211_490456177653518_2055059398_n.jpg but that still might not work. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sat, 22 Jun 2013 23:12:49 -0400, Roy Smith wrote: > In article <51c66455$0$2$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> http://infiniteundo.com/post/25326999628/falsehoods-programmers- believe-about- >> time > > Number 2 on the list is "Months have either 30 or 31 days", which was > obviously believed by whoever made this sign: http://tinyurl.com/mgv39on Can you link directly to the image? Facebook and my browser don't get on. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What is the semantics meaning of 'object'?
On Sat, 22 Jun 2013 19:58:38 -0700, Adam wrote: > class FooBar(object): > def __init__(self): > ... > > Inheritance usually takes a class name to indicate which class is the > 'parent' class. However, in the previous example, from a django book, > the class actually takes an 'object' like parameter, doesn't it? What is > the semantics meaning of such kind of notation? It's not merely notation, "object" is the name of a class. If you type it (without quotes) at the interactive interpreter, you will see it is a built-in class: py> object In Python 3, the use of object as base class is optional, but in Python 2 there is a subtle difference between classes that inherit from object and those that don't. The reason for this difference is buried in the mists of time, going back to Python 2.2. If you are interested, google on "Python unifying types and classes": https://duckduckgo.com/html/?q=Python+unifying+types+and+classes As a general rule, unless you actually want "old-style class" behaviour, you should always inherit from object (or some other built-in type) in Python 2. In Python 3, it doesn't matter. The differences include: * property only works in "new-style" classes that inherit from object; * likewise for super; * multiple inheritance with old-style classes can be buggy; * new-style classes may be slightly faster in general; * on the down side, automatic delegation of special double-underscore methods like __getitem__ and __str__ doesn't work with new-style classes. If none of this means anything to you, be glad, and just inherit from object or some other built-in type in all your classes, and all will be good. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
In article <51c66455$0$2$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about- > time Number 2 on the list is "Months have either 30 or 31 days", which was obviously believed by whoever made this sign: http://tinyurl.com/mgv39on -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie question
On Sat, 22 Jun 2013 19:39:30 -0700, christhecomic wrote:
> Writing simple program asking a question with the answer being
> "yes"...how do I allow the correct answer if user types Yes, yes, or
> YES?
Take the user's input, strip off any whitespace from the beginning and
end, then fold the case to a consistent known form, e.g. lowercase.
# in Python 3.x, use input() rather than raw_input()
result = raw_input("Answer my question! ")
result = result.strip().lower()
if result == "yes":
...
For English words, like "yes", converting to lowercase will do the job.
But if you are using Python 3.3 or better, then I recommend you use
casefold() instead of lower() since that is smarter about converting case
when you have non-English characters.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
What is the semantics meaning of 'object'?
class FooBar(object): def __init__(self): ... Inheritance usually takes a class name to indicate which class is the 'parent' class. However, in the previous example, from a django book, the class actually takes an 'object' like parameter, doesn't it? What is the semantics meaning of such kind of notation? Thanks, /Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, 23 Jun 2013 02:20:56 +0100, MRAB wrote: > One vs not-one isn't good enough. Some languages use the singular with > any numbers ending in '1'. Some languages have singular, dual, and > plural. Etc. It's surprising how inventive people can be! :-) This is a good time to link to these interesting articles: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie question
On Saturday, June 22, 2013 9:39:30 PM UTC-5, christ...@gmail.com wrote: > Writing simple program asking a question with the answer being > "yes"...how do I allow the correct answer if user types Yes, > yes, or YES? Here is a clue. py> 'e' == 'e' True py> 'E' == 'E' True -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie question
On Sun, Jun 23, 2013 at 12:39 PM, wrote: > Writing simple program asking a question with the answer being "yes"...how do > I allow the correct answer if user types Yes, yes, or YES? The thing you're looking for is case-folding, or possibly lower-casing. You should be able to find what you want with that. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
newbie question
Writing simple program asking a question with the answer being "yes"...how do I allow the correct answer if user types Yes, yes, or YES? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 10:48 AM, Rick Johnson
wrote:
> On Saturday, June 22, 2013 6:12:50 PM UTC-5, Chris Angelico wrote:
>> As a general rule, I don't like separating format strings and their
>> arguments.
>
> Huh? Format strings don't take arguments because Python's built-in string
> type is not callable.
>
> py> callable("")
> False
>
> "Format string" is just a generic term we apply to normal string literals
> that include special markers (called "placeholders") that define the final
> location and specify the specifics of an Object(s) translation into string
> type.
And parameterized SQL queries don't take parameters either, for the
same reason. They're extra parameters given to the call that uses it.
So? The format string still takes parameters.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: How can i fix this?
okay i got it thank you all :)) -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 09:20 PM, MRAB wrote: On 23/06/2013 00:56, Dave Angel wrote: Certainly the reorderability of the format string is significant. Not only can it be reordered, but more than one instance of some of the values is permissible if needed. (What's missing is a decent handling of such things as singular/plural, where you want a different version per country of one (or a few) words from the format string, based on whether a value is exactly 1.) [snip] One vs not-one isn't good enough. Some languages use the singular with any numbers ending in '1'. Some languages have singular, dual, and plural. Etc. It's surprising how inventive people can be! :-) And there are plenty more where that came from. Thanks for the reminder. I guess instead of a format, we need a DWIM. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 23/06/2013 00:56, Dave Angel wrote:
On 06/22/2013 07:37 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel wrote:
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
wrote:
_fmtstr = "Item wrote to MongoDB database {0}, {1}"
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format string
**as specified in the physical program**
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language -- blecch.
What I was trying to say is that the programmereze format string in the
code is replaced at runtime by the French format string in the config file.
The simplest way to translate is to localize the format string; that's
the point of .format()'s named argument system (since it lets you
localize in a way that reorders the placeholders). What that does is
it puts the format string away in a config file, while the replaceable
parts are here in the source. That's why I say that's a cost of i18n -
it's a penalty that has to be paid in order to move text strings away.
Certainly the reorderability of the format string is significant. Not
only can it be reordered, but more than one instance of some of the
values is permissible if needed. (What's missing is a decent handling
of such things as singular/plural, where you want a different version
per country of one (or a few) words from the format string, based on
whether a value is exactly 1.)
[snip]
One vs not-one isn't good enough. Some languages use the singular with
any numbers ending in '1'. Some languages have singular, dual, and
plural. Etc. It's surprising how inventive people can be! :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: How can i fix this?
In <54f1fb77-355b-4796-824f-1ee29c402...@googlegroups.com>
=?UTF-8?B?0JHQvtGA0LjRgdC70LDQsiDQkdC+0YDQuNGB0LvQsNCy0L7Qsg==?=
writes:
> > > while 1:
> > > name=raw_input("What is your name? ")
> > > if name == "bobi":
> > print "Hello Master!"
> > break
> > > else: print "error"
> this doesent help me at all
Then you'll have to explain why, exactly, it doesn't help. Simply saying
"this doesn't help me" is very unhelpful to *us*.
Does it produce a syntax error?
Does it run, but produce the wrong output?
Some other reason?
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 22/06/2013 19:49, Rick Johnson wrote: On Saturday, June 22, 2013 12:19:31 PM UTC-5, Rotwang wrote: On 22/06/2013 02:15, Rick Johnson wrote: IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND? No, I don't. These two special cases are not sufficient for me to determine what semantics you are proposing for the general case. QUESTION 1: For example, what happens in the second example if lst is rebound? Well nothing could happen, or something significant could happen. How do you expect me to determine an answer for such a general question when i have no context, or any algorithms to work from. You don't have an algorithm to work from? I assumed you did. If you don't have an algorithm in mind as an alternative to Python's existing behaviour, then what exactly is your point? Anyway, I already proposed an algorithm that is consistent with your examples, in http://mail.python.org/pipermail/python-list/2013-June/650447.html . Is that what you have in mind? Maybe you are trying to set a situation that results in chaos, okay, then chaos will happen. No, I'm not. I'm simply trying to find out what alternative behaviour you're proposing for Python, because the examples you've given so far are not sufficient to explain what happens in the general case. But who's fault is the chaos when a programmer is rebinding names? The programmer is ultimately responsible for his action. Remember my "Apathetic Approach"? QUESTION 2: Does the default stay the same or does it change to the new value of lst? Here you go again, you cannot seem to comprehend very simple concepts. My second example clearly explains what will happen py> lst = range(5) py> lst [0, 1, 2, 3, 4] py> def foo(arg=lst): ... arg.append(1) ... print(arg) ... py> foo() [0, 1, 2, 3, 4, 1] py> foo() [0, 1, 2, 3, 4, 1, 1] No, it doesn't, because lst is not rebound in your second example. As such, entering >>> lst = []; foo() could return [1], or it could return [0, 1, 2, 3, 4, 1, 1, 1]. Both of those could result from behaviours that gave the exact same output as the two examples you've given. It is literally impossible for me to know what you would like to see happen in this case from the limited information you've given me. On the other hand, from the specification I gave earlier it's easy to see that >>> lst = []; foo() would return [1]. Is this what you want? Do you see how the name 'lst' is bound to a list object living in global module scope? Do you see how the default argument (named `arg`) is a reference to a global list named `lst`? ARE YOU FOLLOWING ALONG SO FAR? Since the mutable arg exists OUTSIDE the subroutine, the subroutine merely need to provide access to the global *name* `lst` from within the body of the subroutine, and the subroutine merely do this ONCE at compile time! ARE YOU FAMILIAR WITH THE CONCEPT OF POINTERS? Yes, but Python doesn't have them. Are you proposing that it should have them, and that they should play some role in Python default binding behaviour? If so then a better way of making people aware of this would be to tell them, rather than expecting them to guess and then pretending that their failure to do so represents some failing on their part. QUESTION 3-A: What about if you pass a call as a default argument, and then subsequently change the behaviour of the callable? Hmm, let's have a thought experiment. What if i give you a digital birthday card. And when you open the card you see a friendly note from me: "Rotwang is my best friend in the whole wide world". But unbeknownst to you, i have actually hacked the card and installed a secret wifi device. I've made the message mutable -- hmm, surely nothing "bad" could arise from mutability correct? *evil-grin* A few hours later when you open the card to show to some friends, you are alarmed to see a new message: "Rotwang is a degenerative penis condition" Now, besides being embarrassed, and probably angry as hell, do you understand the dangers of mutable objects? Yes. As I expect you already know, I'm well aware of the dangers of mutable objects. But that isn't what I'm asking you about. I'm asking you what method you propose to avoid one of those dangers. Why don't you just answer the question, instead of answering a different question I didn't ask? I'm not suggesting you don't ever want to use the power of mutability, no, but you do need to have a healthy respect for mutability -- because it can really ruin your day! ==
Re: n00b question on spacing
On Saturday, June 22, 2013 6:12:50 PM UTC-5, Chris Angelico wrote:
> As a general rule, I don't like separating format strings and their
> arguments.
Huh? Format strings don't take arguments because Python's built-in string type
is not callable.
py> callable("")
False
"Format string" is just a generic term we apply to normal string literals that
include special markers (called "placeholders") that define the final location
and specify the specifics of an Object(s) translation into string type.
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 08:27 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel wrote:
On 06/22/2013 07:37 PM, Chris Angelico wrote:
On the contrary, i18n should be done with config files. The format
string
**as specified in the physical program**
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language --
blecch.
What I was trying to say is that the programmereze format string in the code
is replaced at runtime by the French format string in the config file.
But the language is missing the indirection I described. So you have to use
a (function or whatever) wrapper to look up the actual format string in the
config file. My point is by making that file equivalent to a dict, you get
to have an executable program in "programmereze" before creating any config
files, but still able to handle any real language with one config file per
language.
This is much preferable to the usual numeric lookup, where somebody
specifies the 17th format string to be used at this place in the code. Even
when you use C++ names, they're still only a crude approximation to the real
purpose of the string.
What you're saying is that there are ways to ameliorate the problem
with i18n. What that means is that you broadly agree with my main
point, which is that the format string should be kept as close as
possible to the arguments. When you're NOT translating to multiple
languages, the string-literal is the most appropriate way to lay this
out, imo.
Absolutely (very broadly). And when I am, it's still a string literal,
just not the one the customer will see. It still should be next to the
arguments of the format. I'd be replacing something like:
line = "Customer's name: {%0}, address {%1}".format(args)
with
line = i18n(current_language, "Cussom's name: {%0}, addr {%1}", thename,
theaddr)
And the English config file would look like (not counting any escaping
or whatevers):
#SIG - American English, headerline
Cussom's name: {%0}, addr {%1}
Customer's name: {%0}, addr {%1}
The key has the misspelling's and approximations, while the value has
the actual string to be used as the object of format.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel wrote: > On 06/22/2013 07:37 PM, Chris Angelico wrote: >>> On the contrary, i18n should be done with config files. The format >>> string > > > **as specified in the physical program** > > >>> is the key to the actual string which is located in the file/dict. >>> Otherwise you're shipping separate source files for each language -- >>> blecch. > > > What I was trying to say is that the programmereze format string in the code > is replaced at runtime by the French format string in the config file. > > But the language is missing the indirection I described. So you have to use > a (function or whatever) wrapper to look up the actual format string in the > config file. My point is by making that file equivalent to a dict, you get > to have an executable program in "programmereze" before creating any config > files, but still able to handle any real language with one config file per > language. > > This is much preferable to the usual numeric lookup, where somebody > specifies the 17th format string to be used at this place in the code. Even > when you use C++ names, they're still only a crude approximation to the real > purpose of the string. What you're saying is that there are ways to ameliorate the problem with i18n. What that means is that you broadly agree with my main point, which is that the format string should be kept as close as possible to the arguments. When you're NOT translating to multiple languages, the string-literal is the most appropriate way to lay this out, imo. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 07:37 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel wrote:
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
wrote:
_fmtstr = "Item wrote to MongoDB database {0}, {1}"
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format string
**as specified in the physical program**
is the key to the actual string which is located in the file/dict.
Otherwise you're shipping separate source files for each language -- blecch.
What I was trying to say is that the programmereze format string in the
code is replaced at runtime by the French format string in the config file.
The simplest way to translate is to localize the format string; that's
the point of .format()'s named argument system (since it lets you
localize in a way that reorders the placeholders). What that does is
it puts the format string away in a config file, while the replaceable
parts are here in the source. That's why I say that's a cost of i18n -
it's a penalty that has to be paid in order to move text strings away.
Certainly the reorderability of the format string is significant. Not
only can it be reordered, but more than one instance of some of the
values is permissible if needed. (What's missing is a decent handling
of such things as singular/plural, where you want a different version
per country of one (or a few) words from the format string, based on
whether a value is exactly 1.)
But the language is missing the indirection I described. So you have to
use a (function or whatever) wrapper to look up the actual format string
in the config file. My point is by making that file equivalent to a
dict, you get to have an executable program in "programmereze" before
creating any config files, but still able to handle any real language
with one config file per language.
This is much preferable to the usual numeric lookup, where somebody
specifies the 17th format string to be used at this place in the code.
Even when you use C++ names, they're still only a crude approximation to
the real purpose of the string.
The program that's intended to be internationalized is written using
"programmereze" strings. That's a strange inhuman language that's only
approximately comprehensible by the developer and close associates. Then
that gets translated into a bunch of language-specific config files, with
English probably being one of them.
Heh. That's one way of looking at it... I don't really know what
language we speak; at what point is it deemed a separate dialect, and
at what point a unique language? Hmmm.
ChrisA
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 9:28 AM, Dave Angel wrote:
> On 06/22/2013 07:12 PM, Chris Angelico wrote:
>>
>> On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
>> wrote:
>>>
>>>_fmtstr = "Item wrote to MongoDB database {0}, {1}"
>>>msg = _fmtstr.format(_arg1, _arg2)
>>
>>
>> As a general rule, I don't like separating format strings and their
>> arguments. That's one of the more annoying costs of i18n. Keep them in
>> a single expression if you possibly can.
>>
>
> On the contrary, i18n should be done with config files. The format string
> is the key to the actual string which is located in the file/dict.
> Otherwise you're shipping separate source files for each language -- blecch.
The simplest way to translate is to localize the format string; that's
the point of .format()'s named argument system (since it lets you
localize in a way that reorders the placeholders). What that does is
it puts the format string away in a config file, while the replaceable
parts are here in the source. That's why I say that's a cost of i18n -
it's a penalty that has to be paid in order to move text strings away.
> The program that's intended to be internationalized is written using
> "programmereze" strings. That's a strange inhuman language that's only
> approximately comprehensible by the developer and close associates. Then
> that gets translated into a bunch of language-specific config files, with
> English probably being one of them.
Heh. That's one way of looking at it... I don't really know what
language we speak; at what point is it deemed a separate dialect, and
at what point a unique language? Hmmm.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 06/22/2013 07:12 PM, Chris Angelico wrote:
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
wrote:
_fmtstr = "Item wrote to MongoDB database {0}, {1}"
msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
On the contrary, i18n should be done with config files. The format
string is the key to the actual string which is located in the
file/dict. Otherwise you're shipping separate source files for each
language -- blecch.
The program that's intended to be internationalized is written using
"programmereze" strings. That's a strange inhuman language that's only
approximately comprehensible by the developer and close associates.
Then that gets translated into a bunch of language-specific config
files, with English probably being one of them.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sun, Jun 23, 2013 at 1:24 AM, Rick Johnson
wrote:
> _fmtstr = "Item wrote to MongoDB database {0}, {1}"
> msg = _fmtstr.format(_arg1, _arg2)
As a general rule, I don't like separating format strings and their
arguments. That's one of the more annoying costs of i18n. Keep them in
a single expression if you possibly can.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: How can i fix this?
On Sat, Jun 22, 2013 at 3:50 PM, Борислав Бориславов wrote: > this doesent help me at all It shows you how to include multiple statements in the body of the if block. If you're having trouble getting it to work, then please copy and paste the exact code that you're running for us along with the error message that you get. But we can't help you solve your problem if we don't know what it is. -- http://mail.python.org/mailman/listinfo/python-list
Re: How can i fix this?
23 юни 2013, неделя, 00:46:37 UTC+3, Peter Otten написа:
> Борислав Бориславов wrote:
>
>
>
> > while 1:
>
> > name=raw_input("What is your name? ")
>
> > if name == "bobi": print "Hello Master!" and break
>
> > else: print "error"
>
>
>
> > I want if my conditions are met to do a couple of things and i cant do
>
> > that
>
>
>
> > while 1:
>
> > name=raw_input("What is your name? ")
>
> > if name == "bobi":
>
> print "Hello Master!"
>
> break
>
> > else: print "error"
this doesent help me at all
--
http://mail.python.org/mailman/listinfo/python-list
Re: How can i fix this?
On 22/06/2013 22:31, Борислав Бориславов wrote:
while 1:
name=raw_input("What is your name? ")
if name == "bobi": print "Hello Master!" and break
else: print "error"
I want if my conditions are met to do a couple of things and i cant do that
You most certainly can :)
while 1:
name=raw_input("What is your name? ")
if name == "bobi":
print "Hello Master!"
print "Why do some people insist on cramming all of their code
onto one line?"
break
else:
print "error"
--
"Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green." Snooker
commentator 'Whispering' Ted Lowe.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
Re: How can i fix this?
Борислав Бориславов wrote:
> while 1:
> name=raw_input("What is your name? ")
> if name == "bobi": print "Hello Master!" and break
> else: print "error"
> I want if my conditions are met to do a couple of things and i cant do
> that
> while 1:
> name=raw_input("What is your name? ")
> if name == "bobi":
print "Hello Master!"
break
> else: print "error"
--
http://mail.python.org/mailman/listinfo/python-list
How can i fix this?
while 1:
name=raw_input("What is your name? ")
if name == "bobi": print "Hello Master!" and break
else: print "error"
I want if my conditions are met to do a couple of things and i cant do that
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 22/06/2013 03:32, Rick Johnson wrote: On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote: On 22/06/2013 00:51, Rick Johnson wrote: > On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote: > My argument has always been that mutables should not be > passed into subroutines as default arguments because bad > things can happen. [...] I also believe that a programmer > should not be prevented from passing mutable default > arguments [...] So, having mutables as default arguments is a bad idea, but a programmer should not be prevented from doing that, and a warning message should be printed on such occasions. Well i'll admit that does sound like a contradiction. Basically i meant, programmers should be *discouraged* from passing mutables as default arguments but not *prevented*. Of course, utilizing a stateless subroutine like i suggest, argument mutability would not matter. Sometimes when you're passionate about something your explanations become so verbose as to render your idea lost in the noise. Obviously i made that mistake here :) Yes, a more measured explanation tends to work better. :-) In my last reply to Rotwang i explained the functionality i seek to achieve in a set of three interactive examples. Take a look at those and let me know what you think. Hmm. Like they say, "The devil's in the details". As with the mutability thing, I need to think about it some more. Sometimes it seems straight-forward, until you try to do it! :-) > Why should i help the developers of this language. What have > they done for me? They've developed this language, and provided it for free. They've even released the source code. You perceive flaws that you say must be fixed, but you're not going to help to fix them. Agreed. And i am thankful for everyone's contributions. I can be a bit harsh sometimes but my intention has always been to improve Python. I _do_ want you to help to improve the language, and I don't care if you don't get it right first time. I didn't get it right first time when I worked on the regex module (I think that what I have on PyPI is my _third_ attempt!). Well thanks for admitting you are not perfect. I know i am not. We all had to start somewhere and anyone who believes he knows everything is most assuredly a fool. Learning is a perpetual process, same for software evolution. > You want to gain my respect? Then start engaging in honest > debates. Start admitting that yes, somethings about Python > are not only undesirable, they're just plain wrong. Python isn't perfect, but then no language is perfect. There will always be compromises, and the need to maintain backwards compatibility means that we're stuck with some "mis-features", but I think it's still worth using; I still much prefer it to other languages. I understand. We can't break backwards compatibility for everything, even breaking it for some large flaws could cause a fatal abandonment of the language by long time users. I just don't understand why i get so much hostility when i present the flaws for discussion. Part of my intention is to air the flaw, both for new users and old users, but a larger intention is to discover the validity of my, or others, possible solutions. The problem is in _how_ you do it, namely, very confrontationally. You call yourself "RantingRick". People don't like ranting! Instead of saying "This is obviously a flaw, and you're a fool if you don't agree", you should say "IMHO, this is a flaw, and this is how I think it could be fixed". Then, if someone points out a problem in your suggested fix, you can say "OK, I see your point, I'll try to see whether I can think of a way around that". Etc. And even if that solution involves a fork, that is not a bad thing. Creating a new fork and then garnering an acceptance of the new spinoff would lead to at worse, a waste of time and a huge learning experience, or at best, an evolution of the language. > Stop calling me a troll when i am not. And not just me, stop > calling other people trolls too! Stop using the personal > attacks and straw man arguments. Sorry. I failed to explain that this statement was meant not directly for you but as a general statement to all members. Sometimes i feel like my back is against the wall and i'm fighting several foes at once. That can lead to me getting defensive. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
In article
,
Mark Janssen wrote:
> > Also remember when entering long lines of text that strings concatenate
> > within parenthesis.
> > So,
> > ("a, b, c"
> > "d, e, f"
> > "g, h, i")
> >
> > Is the same as ("a, b, cd, e, fg, h, i")
> There was a recent discussion about this (under "implicit string
> concatenation"). It seems this is a part of the python language
> specification that was simply undefined. (A rule probably should be
> added to the lexer to make this explicit.)
This behavior is explicitly defined in the Python Language Reference:
http://docs.python.org/3/reference/lexical_analysis.html#string-literal-c
oncatenation
--
Ned Deily,
n...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Sat, Jun 22, 2013 at 10:49 AM, Dennis Lee Bieber wrote: > On Fri, 21 Jun 2013 19:27:42 -0600, Ian Kelly > declaimed the following: > >>While we're at it, I would like to petition for a function >>terminates(f, args) that I can use to determine whether a function >>will terminate before I actually call it. > > Maybe in a universe with different physical constants... > > Otherwise I think you have encountered > http://en.wikipedia.org/wiki/Halting_problem (consider: could your function > conclude that it terminates when fed it's own code) Yes, that was the joke. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Saturday, June 22, 2013 12:19:31 PM UTC-5, Rotwang wrote: > > On 22/06/2013 02:15, Rick Johnson wrote: > > IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND? > > No, I don't. These two special cases are not sufficient > for me to determine what semantics you are proposing for > the general case. QUESTION 1: > For example, what happens in the second > example if lst is rebound? Well nothing could happen, or something significant could happen. How do you expect me to determine an answer for such a general question when i have no context, or any algorithms to work from. Maybe you are trying to set a situation that results in chaos, okay, then chaos will happen. But who's fault is the chaos when a programmer is rebinding names? The programmer is ultimately responsible for his action. Remember my "Apathetic Approach"? QUESTION 2: > Does the default stay the same or does it change to the > new value of lst? Here you go again, you cannot seem to comprehend very simple concepts. My second example clearly explains what will happen >> py> lst = range(5) >> py> lst >> [0, 1, 2, 3, 4] >> py> def foo(arg=lst): >> ... arg.append(1) >> ... print(arg) >> ... >> py> foo() >> [0, 1, 2, 3, 4, 1] >> py> foo() >> [0, 1, 2, 3, 4, 1, 1] Do you see how the name 'lst' is bound to a list object living in global module scope? Do you see how the default argument (named `arg`) is a reference to a global list named `lst`? ARE YOU FOLLOWING ALONG SO FAR? Since the mutable arg exists OUTSIDE the subroutine, the subroutine merely need to provide access to the global *name* `lst` from within the body of the subroutine, and the subroutine merely do this ONCE at compile time! ARE YOU FAMILIAR WITH THE CONCEPT OF POINTERS? QUESTION 3-A: > What about if you pass a call as a default argument, and > then subsequently change the behaviour of the callable? Hmm, let's have a thought experiment. What if i give you a digital birthday card. And when you open the card you see a friendly note from me: "Rotwang is my best friend in the whole wide world". But unbeknownst to you, i have actually hacked the card and installed a secret wifi device. I've made the message mutable -- hmm, surely nothing "bad" could arise from mutability correct? *evil-grin* A few hours later when you open the card to show to some friends, you are alarmed to see a new message: "Rotwang is a degenerative penis condition" Now, besides being embarrassed, and probably angry as hell, do you understand the dangers of mutable objects? I'm not suggesting you don't ever want to use the power of mutability, no, but you do need to have a healthy respect for mutability -- because it can really ruin your day! QUESTION 3-B: > Does the argument get re-evaluated every time foo() is > called, or is the argument guaranteed to be the same every > time? If the argument is an expression, like a literal, it will be reset to the literal each time the subroutine is called. If the argument is a non-local object, the argument will NOT be reset each time. See "ANSWER 2" for more context. QUESTION 3-C: > If the latter, what happens if the arguments type is > modified (e.g. by changing one of its class attributes)? > What about defining functions dynamically, with default > arguments that are only known at runtime? Is there any way > to avoid the second type of behaviour in this case? If so, > how? If not, isn't that likely to prove at least as big a > gotcha to people who don't know the rules of RickPy as the > problem you're trying to solve? What if X? What if Y? What i pass in a pony but i sell it to a glue factory before the subroutine gets called??? I'm sorry but have no more patience for these ridiculous questions. If you want me to answer *specific* questions, then be sure to ask them one at a time and provide relevant code examples. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 18:28, Alister wrote:
> On Sat, 22 Jun 2013 17:11:00 +0100, Joshua Landau wrote:
>
>> On 22 June 2013 16:55, Rick Johnson
>> wrote:
>>> On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote:
> Plus, your use of the format syntax is incorrect.
Wut?
>>>
>>> Well what i mean exactly is not that it's illegal, i just find the use
>>> of the "getattr sugar", from WITHIN the format string, to be
>>> excessively noisy.
>>
>> Sure...
>> So in other words you realised you were wrong but you're too scared to
>> admit it. Eh? That's it, isn't it! You just don't want to loosen your
>> proud persona :P.
>
> In this argument I tend to find myself siding with Rick.
> Considering his general reputation in this forum am I missing something
> or do I need help? ;-)
I wasn't mocking the preference against it, but rather that that was
completely not what he said originally. One cannot let slip when the
mighty Rick misses his mark.
That said, yes, it is quite a noisy construct. I still prefer it to:
message = "Item wrote to MongoDB database {}/{}"
message = message.format(
settings['MONGODB_DB'],
settings['MONGODB_COLLECTION']
)
log.msg(message, level=log.DEBUG, spider=spider)
Because this feels undescriptive - the first and "second" lines feel
detached. Instead of Rick's hilarious unpacking, you could always do:
message = "Item wrote to MongoDB database {database}/{collection}"
message = message.format(
database=settings['MONGODB_DB'],
collection=settings['MONGODB_COLLECTION']
)
log.msg(message, level=log.DEBUG, spider=spider)
Which is probably as good, if longer. You'll see the real problem is
that "MONDODB_DB" and "MONGODB_COLLECTION" are awful names; would you
really have so detested
message = "Item wrote to MongoDB database "
message +=
"{settings[database]}/{settings[collection]}".format(settings=settings)
log.msg(message, level=log.DEBUG, spider=spider)
or even, now,
message = "Item wrote to MongoDB database
{settings[database]}/{settings[collection]}"
message = message.format(settings=settings)
log.msg(message, level=log.DEBUG, spider=spider)
?
I think those options are quite nice, á mon avis. I could even write a
wrapper (oh noes!):
# Shortened for EMail
class SettingsWrapper:
def uglify_key(self, key): return key if key.startswith("MONGODB")
else "MONGODB_" + key.upper()
def __init__(self, settingsdict): self.wrapped = settingsdict
def __len__(self): return self.wrapped.__len__()
def __iter__(self): return self.wrapped.__iter__()
def __getitem__(self, key): return self.wrapped[self.uglify_key(key)]
def __contains__(self, key): return self.uglify_key(key) in self.wrapped
def __setitem__(self, key, value):
self.wrapped[self.uglify_key(key)] = value
def __delitem__(self, key, value): del self.wrapped[self.uglify_key(key)]
settings = SettingsWrapper(settings)
message = "Item wrote to MongoDB database {settings[db]}/{settings[collection]}"
message = message.format(settings=settings)
log.msg(message, level=log.DEBUG, spider=spider)
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
> Also remember when entering long lines of text that strings concatenate
> within parenthesis.
> So,
> ("a, b, c"
> "d, e, f"
> "g, h, i")
>
> Is the same as ("a, b, cd, e, fg, h, i")
There was a recent discussion about this (under "implicit string
concatenation"). It seems this is a part of the python language
specification that was simply undefined. (A rule probably should be
added to the lexer to make this explicit.)
--
MarkJ
Tacoma, Washington
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Sat, 22 Jun 2013 17:11:00 +0100, Joshua Landau wrote: > On 22 June 2013 16:55, Rick Johnson > wrote: >> On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote: >>> > Plus, your use of the format syntax is incorrect. >>> Wut? >> >> Well what i mean exactly is not that it's illegal, i just find the use >> of the "getattr sugar", from WITHIN the format string, to be >> excessively noisy. > > Sure... > So in other words you realised you were wrong but you're too scared to > admit it. Eh? That's it, isn't it! You just don't want to loosen your > proud persona :P. In this argument I tend to find myself siding with Rick. Considering his general reputation in this forum am I missing something or do I need help? ;-) -- I'm free -- and freedom tastes of reality. -- The Who -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 22/06/2013 03:01, I wrote: On 22/06/2013 02:15, Rick Johnson wrote: [...] This is what should happen: py> def foo(arg=[]): ... arg.append(1) ... print(arg) ... py> foo() [1] py> foo() [1] py> foo() [1] Yes, Yes, YES! That is intuitive! That is sane! Now, what if we pass a reference to a mutable object? What then. Well, let's see: py> lst = range(5) py> lst [0, 1, 2, 3, 4] py> def foo(arg=lst): ... arg.append(1) ... print(arg) ... py> foo() [0, 1, 2, 3, 4, 1] py> foo() [0, 1, 2, 3, 4, 1, 1] That's fine. Because the object was already created OUTSIDE the subroutine. So therefore, modifications to the mutable are not breaking the fundamental of statelessness INSIDE subroutines. The modification is merely a side effect, and the subroutine is unconcerned with anything that exists beyond it's own scope. IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND? No, I don't. These two special cases are not sufficient for me to determine what semantics you are proposing for the general case. For example, what happens in the second example if lst is rebound? Does the default stay the same or does it change to the new value of lst? What about if you pass a call as a default argument, and then subsequently change the behaviour of the callable? Does the argument get re-evaluated every time foo() is called, or is the argument guaranteed to be the same every time? If the latter, what happens if the arguments type is modified (e.g. by changing one of its class attributes)? What about defining functions dynamically, with default arguments that are only known at runtime? Is there any way to avoid the second type of behaviour in this case? If so, how? If not, isn't that likely to prove at least as big a gotcha to people who don't know the rules of RickPy as the problem you're trying to solve? Since you haven't answered this, allow me to suggest something. One thing that a language could do is treat default arguments as mini function definitions with their own scope, which would be the same as the scope of the function itself but without the function's arguments. In other words, in this alternative version of Python, the following >>> def f(x = ): ... would be equivalent, in actual Python, to this: >>> default = lambda: >>> sentinel = object() >>> def f(x = sentinel): ...if x is sentinel: ...x = default() ... That would be something that could be implemented, and as far as I can tell it's consistent with the examples you've given of how you would like Python to work. Is this indeed the kind of thing you have in mind? -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Saturday, June 22, 2013 8:37:20 PM UTC+5:30, Rick Johnson wrote: > I sorry, but FP is not going to wash our sins clean. In > fact, if taken too seriously, FP leads to preaching > professors, intellectually unstimulated students, and > semesters of wasted time that could have been better spent > honing practical *real world* skill sets. > > > > #Tip of the Day# > > # Remember, whilst the professor's tenure will # > # guarantee he gets a paycheck even for producing # > # rubbish, you won't be afforded such luxuries in the # > # real world. # > Here are some examples for your kind consideration. [Something I wrote a few days back with a few additions] Comprehensions and lambdas have come into python. From where? Haskell [Lambdas have even got into C++ !!] LINQ in C# inspired by comprehensions Generics were not there in C# and Java early editions. Now they've been retrofitted -- Origin SML. Almost every modern language supports garbage collection. Origin Lisp Numpy is just APL with python syntax Hottest DBMSes today are the nosql ones -- couchdb written in erlang. Knuth - Vol 1 is a gigantic exercise on how to do lisp without lisp. Also called Greenspun's 10th law: http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming And heard of google? Uses something called map-reduce. Route: APL -> FPLs -> google Yes FP is very academic -- for those living in the last century. I just assumed we are all in 2013 :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 16:55, Rick Johnson wrote: > On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote: >> > Plus, your use of the format syntax is incorrect. >> Wut? > > Well what i mean exactly is not that it's illegal, i just > find the use of the "getattr sugar", from WITHIN the format > string, to be excessively noisy. Sure... So in other words you realised you were wrong but you're too scared to admit it. Eh? That's it, isn't it! You just don't want to loosen your proud persona :P. > In short, i don't care to know WHAT is being injected into > the format string, i simply need to know WHERE it is being > injected. No, I agree. It's never about what you're doing; it's where you are when you do it. > It's about abstractions. It's about not violating the > fundamentals of "templates". Mmhmm, I too treasure these 'fundamentals'. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Saturday, June 22, 2013 10:40:24 AM UTC-5, Joshua Landau wrote: > > Plus, your use of the format syntax is incorrect. > Wut? Well what i mean exactly is not that it's illegal, i just find the use of the "getattr sugar", from WITHIN the format string, to be excessively noisy. In short, i don't care to know WHAT is being injected into the format string, i simply need to know WHERE it is being injected. It's about abstractions. It's about not violating the fundamentals of "templates". -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 14:36, Joshua Landau wrote:
> My favourite way would be along the lines of:
>
> message = "Item wrote to MongoDB database "
> message += "{0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}".format(settings)
> log.msg(message, level=log.DEBUG, spider=spider)
To make a habit of replying to myself, I thought I'd point out I wrote
it this way mostly because I have no idea how big "settings" is.
If it's not large and only contains keys that are valid identifiers,
it'd be more readable to write:
message = "Item wrote to MongoDB database "
message += "{MONGODB_DB}/{MONGODB_COLLECTION}".format(**settings)
log.msg(message, level=log.DEBUG, spider=spider)
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 16:24, Rick Johnson wrote:
> On Saturday, June 22, 2013 8:36:43 AM UTC-5, Joshua Landau wrote:
>> message = "Item wrote to MongoDB database "
>> message += "{0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}".format(settings)
>> log.msg(message, level=log.DEBUG, spider=spider)
>
> If you're going to whore out parts of the string to
> variables i would suggest going for the gold and actually
> make it readable.
Erm, as you wish.
> Plus, your use of the format syntax is
> incorrect.
Wut?
> _arg1 = settings['MONGODB_DB']
> _arg2 = settings['MONGODB_COLLECTION']
> _fmtstr = "Item wrote to MongoDB database {0}, {1}"
> msg = _fmtstr.format(_arg1, _arg2)
> log.msg(msg, level=log.DEBUG, spider=spider)
>
> If you want readability, now you got it.
If you say so.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Saturday, June 22, 2013 8:37:20 PM UTC+5:30, Rick Johnson wrote: > > So for example, if the use-case contained a statement > > like: In order to safeguard customer-satisfaction, the > > ATM's performance shall not degrade beyond 3 seconds > > response time. > > So now - according to our methodology - we need to > > make performance, response-time and even customer- > > satisfaction(!!) into classes. > > LOL! > > Only a fool, or a religious OOP extremist, would create > custom objects for such things. Although, if he were forced > to use Java, he wouldn't have any choice would he? Poor > basterd! >:D Shall I quote something of yours to Steven about "the ability to recognize sarcasm?" On a more serious note, Ian's terminate function, or Chris' bug-free function which is the same by Rice theorem are different variants of the same thing: some of the most key things of concern to the programmer cannot be modeled/reified into his program. > The point is, no one paradigm is going to save us from the > devil. We must take from each style it's positive > attributes, and reject it's negative attributes. The art of > intelligently applying multiple paradigms to solve complex > problems should be held up as the pinnacle of greatness. If > your going to worship something, worship achievement. Ok -- I agree. -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On Saturday, June 22, 2013 8:36:43 AM UTC-5, Joshua Landau wrote:
> message = "Item wrote to MongoDB database "
> message += "{0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}".format(settings)
> log.msg(message, level=log.DEBUG, spider=spider)
If you're going to whore out parts of the string to
variables i would suggest going for the gold and actually
make it readable. Plus, your use of the format syntax is
incorrect.
_arg1 = settings['MONGODB_DB']
_arg2 = settings['MONGODB_COLLECTION']
_fmtstr = "Item wrote to MongoDB database {0}, {1}"
msg = _fmtstr.format(_arg1, _arg2)
log.msg(msg, level=log.DEBUG, spider=spider)
If you want readability, now you got it.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
> See my blog [...] > for a history of wishes akin to yours and lessons not > learnt. In short the problems accruing from unconstrained > imperative programming are severe and the solutions are > hard. In the meanwhile, goals such as your 'keep- > procedures-stateless' can and should certainly be > practised in the human sphere even if not implemented in > the programming language sphere. The aggregation of such > 'best-practices' is what I call FP as an ideology rather > than as technology. > > I have a collection here [...] > And I would welcome suggestions/discussions on the same. Here are some statements from your blog, i have made a few tweaks to the text (mainly structure) so as to render it more readable. > Unfortunately these are the exceptions. In the vast > majority of cases, the quest for generalities only > produces rubbish. So lets see how the... The Philosophy of > OO fares in this regard. > > OO starts off its philosophical sojourn with the dogma: > Everything is an object I will start with a variation that > is slightly less nonsensical but easier to debunk; > Everything can be modeled as a class > > Now if we start looking at the justifications of this > statement we would find certain methodological directives > such as Identify the nouns in the use-case and make them > classes In itself this is - as a methodology - not > objectionable. > > So for example if we are presented with the standard > example of a customer coming to an ATM and making a > transaction, this methodology tells us that it may be a > good idea to make customer and ATM into classes - so far > so good. > > And what about transaction? Yes we could make it into a > class also, but as we shall see, blanket- adding the set > of abstract nouns into the set of common nouns as class- > ifiable objects gets us into trouble. No, the transaction itself need NOT be a custom object. > So for example, if the use-case contained a statement > like: In order to safeguard customer-satisfaction, the > ATM's performance shall not degrade beyond 3 seconds > response time. > So now - according to our methodology - we need to > make performance, response-time and even customer- > satisfaction(!!) into classes. LOL! Only a fool, or a religious OOP extremist, would create custom objects for such things. Although, if he were forced to use Java, he wouldn't have any choice would he? Poor basterd! >:D But my point is, OOP is not a cure-all for every problem, in fact, it can overly complicate many problems. For instance, being forced to write an object definition for a simple hello world program in Java is nothing less than pure sadism -- but that's why i don't use Java unless i'm forced! OTOH, from skimming a few other threads in your blog, you seem to long for some salvation of FP to save all our souls from the eternal damnation of IP, like a Christian longing for the second coming of Christ! "Take us away to streets paved in gold!" I sorry, but FP is not going to wash our sins clean. In fact, if taken too seriously, FP leads to preaching professors, intellectually unstimulated students, and semesters of wasted time that could have been better spent honing practical *real world* skill sets. #Tip of the Day# # Remember, whilst the professor's tenure will # # guarantee he gets a paycheck even for producing # # rubbish, you won't be afforded such luxuries in the # # real world. # "If it IS to be, then it's up to ME" The point is, no one paradigm is going to save us from the devil. We must take from each style it's positive attributes, and reject it's negative attributes. The art of intelligently applying multiple paradigms to solve complex problems should be held up as the pinnacle of greatness. If your going to worship something, worship achievement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
Op 22-06-13 03:27, Ian Kelly schreef: On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano wrote: On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote: On 21/06/2013 21:44, Rick Johnson wrote: [...] Which in Python would be the "MutableArgumentWarning". *school-bell* I notice that you've omitted any mention of how you'd know that the argument was mutable. That's easy. Just call ismutable(arg). The implementation of ismutable is just an implementation detail, somebody else can work that out. A language designer of the sheer genius of Rick can hardly be expected to worry himself about such trivial details. While we're at it, I would like to petition for a function terminates(f, args) that I can use to determine whether a function will terminate before I actually call it. Are you two guys now egging on Rick Johnson? -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22/06/2013 14:36, Joshua Landau wrote:
On 21 June 2013 23:26, Gary Herron wrote:
On 06/21/2013 02:17 PM, Yves S. Garret wrote:
I have the following line of code:
log.msg("Item wrote to MongoDB database %s/%s" %(settings['MONGODB_DB'],
settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider)
<...>
I was thinking of splitting it up like so:
log.msg("Item wrote to MongoDB database %s/%s"
%(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
This is how I'd do it: (And it's *FAR* clearer -- You win no points for
clarity by having it all in one statement.)
fmt = "Item wrote to MongoDB database %s/%s"
msg = fmt % (settings['MONGODB_DB'],
settings['MONGODB_COLLECTION'])
log.msg(msg, level=log.DEBUG, spider=spider)
Hear, Hear.
But really, you should be using .format by now :P
My favourite way would be along the lines of:
message = "Item wrote to MongoDB database "
message += "{0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}".format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
I'm sticking with C style formatting, which thankfully isn't going away,
.format indeed.
--
"Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green." Snooker
commentator 'Whispering' Ted Lowe.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 22 June 2013 14:36, Joshua Landau wrote: > message = "Item wrote to MongoDB database " Pedant's note: "Item *written* to MongoDB database" -- http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
On 21 June 2013 23:26, Gary Herron wrote:
> On 06/21/2013 02:17 PM, Yves S. Garret wrote:
>> I have the following line of code:
>> log.msg("Item wrote to MongoDB database %s/%s" %(settings['MONGODB_DB'],
>> settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider)
<...>
>> I was thinking of splitting it up like so:
>> log.msg("Item wrote to MongoDB database %s/%s"
>> %(settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
>> level=log.DEBUG, spider=spider)
>
> This is how I'd do it: (And it's *FAR* clearer -- You win no points for
> clarity by having it all in one statement.)
>
> fmt = "Item wrote to MongoDB database %s/%s"
> msg = fmt % (settings['MONGODB_DB'],
> settings['MONGODB_COLLECTION'])
> log.msg(msg, level=log.DEBUG, spider=spider)
Hear, Hear.
But really, you should be using .format by now :P
My favourite way would be along the lines of:
message = "Item wrote to MongoDB database "
message += "{0[MONGODB_DB]}/{0[MONGODB_COLLECTION]}".format(settings)
log.msg(message, level=log.DEBUG, spider=spider)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Simple I/O problem can't get solved
Chris Angelico wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Peter Otten <__pete...@web.de> wrote:
>> Combining these modifications:
>>
>> for line in f:
>> word = line.strip()
>> if is_palindrome.is_palindrome(word):
>> print word
>
> Minor quibble: I wouldn't use the name 'word' here, unless you're
> expecting the file to consist of one-word lines (such as DICTOT.DIC
> from old PMMail). For detecting phrase/sentence palindromes, I'd keep
> the name 'line'.
Somehow it didn't occur to me that you might test anything but words.
However, if you want to check sentences (as some unused code in the original
post suggests) I think you should not strip off the newline and leave the
necessary cleanup to the test function:
>>> def is_palindrome(s):
... t = "".join(c for c in s.casefold() if c.isalnum())
... return t == t[::-1]
...
>>> is_palindrome("A man, a plan, a canal - Panama!\n")
True
--
http://mail.python.org/mailman/listinfo/python-list
Re: Simple I/O problem can't get solved
On Fri, Jun 21, 2013 at 7:15 PM, Peter Otten <__pete...@web.de> wrote: > Combining these modifications: > > for line in f: > word = line.strip() > if is_palindrome.is_palindrome(word): > print word Minor quibble: I wouldn't use the name 'word' here, unless you're expecting the file to consist of one-word lines (such as DICTOT.DIC from old PMMail). For detecting phrase/sentence palindromes, I'd keep the name 'line'. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 22/06/2013 02:31, Steven D'Aprano wrote:
On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:
Oh! I know. Function argument defaults will now be restricted to
int/float/tuple. That would do it, right? Nobody would be bothered by
little restrictions like that, would they.
Alas, tuples won't do it. Fortunately, you can include str and bytes
(unicode and str) and frozenset in the "Good List". Tuples have to go
into the "Bad List" because, although they themselves are immutable,
their contents may not be. Imagine the confusion and horror that poor
developers will experience when they do something like this:
def func(arg, extra=(23, 'foo', [])):
[code goes here...]
extra[2].append("something")
[more code...]
and they've now mutated the immutable default!
Thinking about this, I think that the only safe thing to do in Rickython
4000 is to prohibit putting mutable objects inside tuples. Putting a list
or a dict inside a tuple is just a bug waiting to happen!
How about naming the fork RickedPython 4000, where ricked is defined
here http://www.urbandictionary.com/define.php?term=ricked ?
--
"Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green." Snooker
commentator 'Whispering' Ted Lowe.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
Re: n00b question on spacing
"Yves S. Garret" writes:
> I have the following line of code:
> log.msg("Item wrote to MongoDB database %s/%s" %(settings['MONGODB_DB'],
> settings['MONGODB_COLLECTION']), level=log.DEBUG, spider=spider)
[…]
> Is this ok? Are there any rules in Python when it comes to breaking up
> long lines of code?
PEP 8 is the common denominator; follow its restrictions and your code
will be a lot more readable to just about any Python programmer. So,
indent 4 columns for block structure, preferably 8 columns for
continuation lines, put spaces around binary operators, etc.
As for *where* to break long lines: I prefer the continuation lines to
be a standard indentation (4 or 8 columns), which means the indentation
doesn't need to change when the first line changes later. So I break at
an open paren, brace, bracket (‘(’, ‘{’, ‘[’) etc. and allow Python to
automatically continue the statement until that bracketing is closed.
log.msg(
"Item wrote to MongoDB database %s/%s"
% (settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
That way, if the first line changes later, you don't need to change any
of the indentation on the continuation lines:
logger.info(
"Item wrote to MongoDB database %s/%s"
% (settings['MONGODB_DB'], settings['MONGODB_COLLECTION']),
level=log.DEBUG, spider=spider)
--
\ “[W]e are still the first generation of users, and for all that |
`\ we may have invented the net, we still don't really get it.” |
_o__) —Douglas Adams |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
