Re: downcasting problem
> Hi everybody, > > I need to downcast an object, and I've read repeatedly that if you > need to downcast, you did something wrong in the design phase. So, > instead of asking how do you downcast in python, let me explain my > situation. > > I have a 2-pass parser. 1st pass ends up with a bunch of superclass > object, and 2nd pass is supposed to downcast those to one of > subclasses so I can work with them. > > Details: > > I have a file full of lines which I parse into Line objects. I also > have two subclasses of Line, namely Individual and Family. Constructor > of both subclasses needs all Line objects in the file to be > constructed, so I cannot construct subclass objects in the first pass. > > The Python way of doing this (as I understand it) would be to wrap a > subclass around Line and have the Line object as an attribute of a > subclass. Now, this obviously breaks polymorphism and I now have to > reimplement all of Line's classes in subclasses. Although > reimplementation is simple (def method(self): return > self.line.method()), that way of doing things is just not elegant. > So, is there any more elegant solution to my problem? Why not have an abstract Line class with your Line methods, a SimpleLine (your current Line class, extends AbstractLine), and IndividualLine and FamilyLine (both extending AbstractLine)? Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Help needed - To get path of a directory
> Dear Emmanuel, > > Thank you for your reply. > Actually what I want to do is, at the run time I want to know the location > of a specific directory. > Then I will add some file name to the path and load the file. > The directory can reside in any drive, depending on the user. Well... If you don't even know the path of the directory relative to the root of the drive... I hope your user is not in any hurry. Scanning a single drive is potentially very time-consuming, scanning them all will be awful (especially if your user has mounted, say, a huge network drive...). Don't you have any other, smarter way of finding out the directory? Like reading a configuration file or an entry in the registry? Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Exceptions are not just for errors (was: My first Python program)
> Seebs writes: > > On 2010-10-13, Chris Rebert wrote: > > > For future reference, the significant majority of things in Python > > > raise exceptions upon encountering errors rather than returning > > > error values of some sort. > > > > Yes. I'm getting used to that -- it's a bit of a shift, because I'm > > used to exceptions being *exceptional* -- as in, not a failure mode > > you would expect to see happening. > > From that expectation, it's an even more fundamental shift. Python > encourages (and tends toward) raising exceptions in any exceptional > circumstance — that is, in any circumstance that isn't the usual > behaviour for the function. > > So, for example, an exception (StopIteration) is how iterables signal > that they've finished iterating; but that's not an error, only an > exception. Likewise for the ‘str.index’ example given earlier. I'd say more succintly that Python uses (at times) exception for flow control. Whether that's elegant or not is debatable. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Help needed - To get path of a directory
> Dear All,
>
> I want to get the absolute path of the Directory I pass explicitly. Like
>
> functionName("\abcd").
> I should pass the name of the directory and the function should search for
> it in the Hard drives and return me the full path of location on the drive.
> I tried using os.path, but didn't succeed.
>
> I am using python 2.5 on windows platform.
> It will be very kind of you if you can guide me on this.
What is your path relative to? The python file? The working directory? Can it
be absolute? Or do you actually intend to "search for it in the hard drives"
because you don't know where it is?
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: Testing for changes on a web page (was: how to find difference in number of characters)
> On Oct 9, 5:41 pm, Stefan Behnel wrote: > > "Number of characters" sounds like a rather useless measure here. > > What I meant by number of characters was the number of edits happened > between the two versions..Levenshtein distance may be one way for > this..but I was wondering if difflib could do this > regards As pointed out above, you also need to consider how the structure of the web page has changed. If you are only looking at plain text, the Levenshtein distance measures the number of edit operations (insertion, deletion or substition) necessary to transform string A into string B. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Control webbrowser from Python script
> Is it possible to control any webbrowser from Python ? For example to > issue http POST and GET command > Thanks > Johny http://docs.python.org/library/webbrowser.html The control you get is rather limited, though. If your aim is interacting with a website, though, you can try urllib/urllib2 for simple things, and Mechanize ( http://wwwsearch.sourceforge.net/mechanize/ ) or Twill ( http://twill.idyll.org/ ) for more complex operations. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: getopt not raising exception
> Matt Nordhoff wrote: > > BTW: Checked out optparse? It's bigger and sexier! If you're doing things with positional arguments, you should consider using argparse (http://argparse.googlecode.com/svn/tags/r101/doc/index.html). It's like optparse, but (much) better. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Frameworks
> Emmanuel Surleau a écrit : > >>>>> It still manages to retain flexibility, but you're basically stuck > >>>>> with Django's ORM > >>>> > >>>> You're by no way "stuck" with Django's ORM - you are perfectly free > >>>> not to use it. But then you'll obviously loose quite a lot of useful > >>>> features and 3rd part apps... > >>> > >>> You lose most of what makes it worth using Django, > >> > >> Mmmm... I beg to disagree. You still have the core framework (request / > >> response handling, sessions etc), the templating system, the form API > >> etc. As far as I'm concerned, it's quite enough to "make it worth". > > > > The form API is pretty good, but I don't think the rest makes it stand > > out that much, compared to other frameworks. > > I don't care if it "stand out that much" - it works fine and is well > documented. Given that for most web apps, Django's ORM is a good enough > tool, I don't see the point in using 3 or more "different" frameworks > that basically do the same things in slightly different ways, each with > it's own strong and weak points. I think we'd be lucky to have just 3 :) But there are obviously advantages to something more modular like Pylons, and Tornado looks interesting as well (haven't used it yet, though). That's open-source for you. > > To me, the notion of reusable apps > > and the application ecosystem it allows is Django's most compelling > > feature. > > +1. Thinking about it, that's where modularity can hurt, eg, Pylons. Developing a "reusable app" like Django's is more difficult if you don't know what ORM or templating system is being used. Unless you stick to the most popular choices, but this removes, in practice, flexibility for developers who need such apps. > > You are, of course, welcome to disagree. > > I'm not saying that Django is "better" than Pylons or web.py or (insert > yur favorite framework here) - and to be true, I think Pylons is > globally smarter than Django -, I'm saying that it do the job, and do it > well enough to be worth using. Sorry for being so pragmatic. > > >>> Having to implement a mini-parser for > >>> each single tag > >> > >> Most of the "mini-parser" stuff is so very easily factored out I'm > >> afraid I won't buy your argument. > > > > You'll at least agree that in terms of line of codes necessary to > > implement a custom tag, it's very far from optimal, I hope? > > I also agree that in terms of LOCs necessary to implement a log file > parser, Python is also very far from optimal, at least compared to Perl !-) I think that depends on how many regular expressions you use in your code. Think about all these lines with } you don't need any more. As far as languages go, Python strikes a good balance between readability and concision, really. > How many Django custom tags did you write, exactly ? And of which level > of complexity ? Once again, I'm not pretending Django is the best thing > ever, but most of your remarks remind me of what I once could have say - > that is, before having enough experience writing and maintaining Django > apps. One of the greatest features of Django - and possibly what finally > makes it so pythonic - is that it doesn't try to be *too* smart - just > smart enough. I'll grant you I don't have a huge experience with Django custom tags (or Django in general). Should I do more Django in the future, custom tags would irk me less (after all, I even got used to ASP, so...). This still does not make them particularly practical, though I agree that they are not a huge inconvenience. -- http://mail.python.org/mailman/listinfo/python-list
Re: Frameworks
> Emmanuel Surleau a écrit : > >> Emmanuel Surleau a écrit : > >>>> Django : very strong integration, excellent documentation and support, > >>>> huge community, really easy to get started with. And possibly a bit > >>>> more mature and stable... > >>> > >>> One strong point in favour of Django: it follows Python's philosophy of > >>> "batteries included", and features a large array of plugins. There are > >>> also numerous other add-ons created by the community. > >>> > >>> Also, it has a pretty great administration interface. > >>> > >>> It still manages to retain flexibility, but you're basically stuck with > >>> Django's ORM > >> > >> You're by no way "stuck" with Django's ORM - you are perfectly free not > >> to use it. But then you'll obviously loose quite a lot of useful > >> features and 3rd part apps... > > > > You lose most of what makes it worth using Django, > > Mmmm... I beg to disagree. You still have the core framework (request / > response handling, sessions etc), the templating system, the form API > etc. As far as I'm concerned, it's quite enough to "make it worth". The form API is pretty good, but I don't think the rest makes it stand out that much, compared to other frameworks. To me, the notion of reusable apps and the application ecosystem it allows is Django's most compelling feature. You are, of course, welcome to disagree. > > Having to implement a mini-parser for > > each single tag > > Most of the "mini-parser" stuff is so very easily factored out I'm > afraid I won't buy your argument. You'll at least agree that in terms of line of codes necessary to implement a custom tag, it's very far from optimal, I hope? Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Frameworks
> On Oct 20, 2009, at 4:59 PM, Emmanuel Surleau wrote:
> > Compared to custom tags in, say, Mako? Having to implement a mini-
> > parser for
> > each single tag when you can write a stupid Python function is
> > needless
> > complication.
>
> I like Mako a lot and in fact web2py template took some inspiration
> from it. Here is a mako example:
>
> % for a in ['one', 'two', 'three', 'four', 'five']:
> % if a[0] == 't':
> its two or three
> % elif a[0] == 'f':
> four/five
> % else:
> ${a}
> %endif
> % endfor
>
>
> Here is the same in web2py-ese, translated line by line
>
> {{for a in ['one', 'two', 'three', 'four', 'five']:}}
> {{if a[0] == 't':}}
> its two or three
> {{elif a[0] == 'f':}}
> four/five
> {{else:}}
> {{=a}}
> {{pass}}
> {{pass}}
>
> Legend Mako -> web2py
> % -> {{ }}
> endif -> pass
> endfor -> pass
> ${...} -> {{=...}}
>
> Mako introduces terms like "endif", "endfor" which are not Python
> keywords. Web2py only uses valid python keywords.
Ingenious. Web2py looks more consistent (everything relies on {{ }} while Mako
uses %, $ and <% >). On the other hand, the Mako syntax is a bit lighter to my
eyes. Tradeoffs, tradeoffs...
> Here is another example, in Mako:
>
> <%def name="myfunc(x)">
> this is myfunc, x is ${x}
>
> ${myfunc(7)}
>
> and the same in web2py
>
> {{def myfunc(x):}}
> this is myfunc, x is {{=x}}
> {{return}}
> {{myfunc(7)}}
>
> Again web2py does not introduce any new syntax. only valid Python in
> {{...}} tags.
> (Notice {{myfunc(7)}} not {{=myfunc(7)}} becase the function is
> printing, we are not printing the return value of the function).
>
> Mako needs to parse % ..., <%>..., ... and ${...}. web2py needs to
> parse only {{...}}.
>
> The use of {{...}} in web2py is inspired by Django. This has a big
> advantage over <%...%>, it is transparent to html editors and so you
> use any html editor with the templates.
Bah, as if anyone needed anything else than vim :) Just joking, I see the
advantage if you are working with external designers.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: Frameworks
> Emmanuel Surleau a écrit : > >> Django : very strong integration, excellent documentation and support, > >> huge community, really easy to get started with. And possibly a bit more > >> mature and stable... > > > > One strong point in favour of Django: it follows Python's philosophy of > > "batteries included", and features a large array of plugins. There are > > also numerous other add-ons created by the community. > > > > Also, it has a pretty great administration interface. > > > > It still manages to retain flexibility, but you're basically stuck with > > Django's ORM > > You're by no way "stuck" with Django's ORM - you are perfectly free not > to use it. But then you'll obviously loose quite a lot of useful > features and 3rd part apps... You lose most of what makes it worth using Django, so you're in effect kind of stuck with it. If you don't need/want the ORM, you might as well use something else. > > (which is OK for simple things) and templating language (which is > > OK as long as you don't need custom tags). > > Custom tags are nothing complicated. Compared to custom tags in, say, Mako? Having to implement a mini-parser for each single tag when you can write a stupid Python function is needless complication. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Frameworks
> Django : very strong integration, excellent documentation and support, > huge community, really easy to get started with. And possibly a bit more > mature and stable... One strong point in favour of Django: it follows Python's philosophy of "batteries included", and features a large array of plugins. There are also numerous other add-ons created by the community. Also, it has a pretty great administration interface. It still manages to retain flexibility, but you're basically stuck with Django's ORM (which is OK for simple things) and templating language (which is OK as long as you don't need custom tags). > Pylons : more loosely coupled (imply: less integration), based on > "standard" components - which is both a blessing and a curse, specially > wrt/ documentation -, requires a good knowledge of Python and the HTTP > protocol to get started with. Very powerful and flexible but this comes > with a price... Haven't used Pylons, but the documentation has improved the last few years with the Pylons book (http://pylonsbook.com/en/1.0/), while still not being up to par with Django's. It has also a methodology for deployment, which Django decidedly lacks. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Questions on XML
On Saturday 22 August 2009 08:13:33 joy99 wrote: > On Aug 22, 10:53 am, Stefan Behnel wrote: > > Rami Chowdhury wrote: > > >> I am using primarily UTF-8 based strings, like Hindi or Bengali. Can I > > >> use Python to help me in this regard? > > > > > > I can say from experience that Python on Windows (at least, Python 2.5 > > > on 32-bit Vista) works perfectly well with UTF-8 files containing > > > Bangla. I have had trouble with working with the data in IDLE, however, > > > which seems to prefer ASCII by default. > > > > Defaults almost never work for encodings. You have to be explicit: add an > > encoding declaration to the top of your source file if you use encoded > > literal strings in your code; use the codecs module with a suitable > > encoding to read encoded text files, and use an XML parser when reading > > XML. > > > > Stefan > > Dear Group, > Thanx for your reply. Python works perfectly for Hindi and Bangla with > Win XP. I never had a trouble. > Best Regards, > Subhabrata. You might also want to have a look at lxml. It can much more than the XML module in the default distribution, uses ElementTree as well, and is backed by the kickass, fast libxml library (http://codespeak.net/lxml/). It will allow you to use XSLs, for instance. Regardless of whether you use lxml or not, have a look at etree.iterparse, it is invaluable when processing huge XML documents. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Questions on XML
> >> I am using primarily UTF-8 based strings, like Hindi or Bengali. Can I > >> use Python to help me in this regard? > > > > I can say from experience that Python on Windows (at least, Python 2.5 > > on 32-bit Vista) works perfectly well with UTF-8 files containing > > Bangla. I have had trouble with working with the data in IDLE, however, > > which seems to prefer ASCII by default. > > Defaults almost never work for encodings. You have to be explicit: add an > encoding declaration to the top of your source file if you use encoded > literal strings in your code; use the codecs module with a suitable > encoding to read encoded text files, and use an XML parser when reading > XML. Actually, default *should* work for XML. The default encoding for an XML file is UTF-8 (AFAIK). Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
> It's a particular unfair criticism because the critic (Ethan Furman) > appears to have made a knee-jerk reaction. The "some language in Python" > behaviour he's reacting to is the common idiom: > > for i in range(len(seq)): > do_something_with(seq[i]) > > > instead of the "Python in Python" idiom: > > for obj in seq: > do_something_with(obj) > > > That's a reasonable criticism, but *not in the case*. Ethan appears to > have made the knee-jerk reaction "for i in range() is Bad" without > stopping to think about what this specific piece of code is actually > doing. > > (Replace 'obj' with 'j', 'seq' with 'range(2, n)', and > 'do_something_with' with 'if (n % j) == 0: return False', and you have > the exact same code pattern.) Fair enough. But as far as I know, for i in (x)range(num) is the canonical way to iterate over numbers in Python. Another case of lack of RTFM* before answering, I suppose. Cheers, Emm *Read The Fine Mail -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
> Dr. Phillip M. Feldman wrote: [snip] > > def is_prime(n): > >for j in range(2,n): > > if (n % j) == 0: return False > >return True > > > > It seems as though Python is actually expanding range(2,n) into a list of > > numbers, even though this is incredibly wasteful of memory. There should > > be a looping mechanism that generates the index variable values > > incrementally as they are needed. > > You already have an answer to the range issue, so I will only add that > putting a loop inside another loop is a decent way to expand the time > taken. > > I will also observe that if you were to stop programming whatever > language you are more familiar with in Python, and start programming > Python in Python, you'll have an easier time of it. I don't see what's particularly un-Pythonic with this code. Not using xrange() is a mistake, certainly, but it remains clear, easily understandable code which correctly demonstrates the naive algorithm for detecting whether n is a prime. It doesn't call for condescension > The Dive Into Python is an excellent start for that. I never read it, but I was under the impression that the tutorial on python.org was geared toward programmers moving to Python from other languages. It was also my impression that Dive Into Python is rather outdated and occasionally inaccurate (based on comments on this mailing list). Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
On Saturday 01 August 2009 03:46:12 Steven D'Aprano wrote:
> On Fri, 31 Jul 2009 20:41:12 +0200, Emmanuel Surleau wrote:
> >> We don't actually *declare* that something is constant and then have
> >> that declaration ignored. Python doesn't lie to us, although (as in any
> >> language) a programmer might.
> >
> > You could say that Ruby doesn't either,
>
> Well you could say a lot of things. Admittedly you don't need a separate
> "constant" declaration, but creating a variable name with an initial
> uppercase letter is sufficient to make it a (supposed) constant:
*shrugs* I see it as a way to encourage (but not force) people to follow a
coding convention. Is this such a bad thing?
> irb(main):049:0* Thing = 5
> => 5
> irb(main):050:0> Thing = 7
> (irb):50: warning: already initialized constant Thing
> => 7
>
> As you can see, Ruby (well, irb at least) considers that Thing is a
> constant, and then goes ahead and changes it anyway.
I'm quite aware of how constants work in Ruby, yes :)
> Apart from the use of an arbitrary naming convention instead of an
> explicit "make this constant" declaration, and the feeble way Ruby
> capitulates when you change it, I think having actual write-once
> constants is actually a plus.
Nothing wrong with naming conventions. This encourages a uniform coding style,
something which Python could really use.
> > you just need to read the
> > documentation. Ruby's unwritten motto is "flexibility über alles". In
> > this regard, it is consistent (1).
>
> "It's consistent in its inconsistency" sort of thing perhaps?
No, just consistent.
> > Not much is really bolted down in
> > Ruby. You get encapsulation, but it's so easy to break that it's mostly
> > symbolic.
>
> Out of curiosity, can you read/write class and instance attributes from
> outside the class without using a getter/setter?
If you have an instance f class with a attribute @foo which doesn't have an
accessor, you could do:
f.instance_eval("@foo='bar'")
And yes, instance_eval is evil.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python docs disappointing
On Friday 31 July 2009 22:10:45 kj wrote: > I'm pretty new to Python, and I like a lot overall, but I find the > documentation for Python rather poor, overall. > > I'm sure that Python experts don't have this problem: they have > internalized some good ways to access the documentation, are > productive with it, and therefore have lost the ability to see why > the Python documentations is deficient for beginners. This explains > why a suboptimal situation can persist like this: those who are > most able fix it are also the least able to perceive it. > > I've heard similar complaints from other experienced programmers > who are trying out Python for the first time: poor documentation. The documentation on python.org is quite extensive. In particular, you may want to look at the PEPs, which offer fascinating insights for the reasoning behind particular features of Python. > Here is an *entirely typical* example: on some Unix, try > > % pydoc urllib > > The displayed documentation mention the optional parameter "data" > in practically every function listed (a few dozen of them). This > parameter is not documented *anywhere* on that page. All that we > are told is that its default value is always None. > > I'm sure that I can find a full description of this parameter if > I fire up Google, and search online. In fact, more likely than > not, I'll find far more documentation than I want. But my point > is that a programmer should not need to do this. The full > documentation should be readily accessible directly through a few > keystrokes. You have first-grade documentation on the Python website: http://docs.python.org/library/urllib.html I'm not really using pydoc, but I'd wager it's more used as a quick lookup than anything else. > I would love to know how experienced Python programmers quickly > zero in on the Python documentation they need. I wouldn't count myself as an 'experienced' Python programmer, but I rely on docs.python.org for most things with regards to the standard library. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Help understanding the decisions *behind* python?
On Friday 31 July 2009 21:55:11 Terry Reedy wrote: > Emmanuel Surleau wrote: > >> Beyond the mutable/hashable distinction, there is an important > >> philosophical distinction articulated by Guido. He deems tuples to > >> be useful for struct like groupings of non-homogenous fields and > >> lists to be useful for sequences of homogenous data suitable for > >> looping. > > I think the use of the with 'homegeneous' in this context is wrong > because 1) it is ambiguous or even sometimes not the case, and 2) it > misleads. Everything is an object, so all collections are in that sense > homogeneous. If the meaning is restricted to type(ob), than a list > 'mixing' ints and floats would be non-homogeneous and not 'legitimate', > but Guido does not really mean that. > > The word tuple comes from relational databases as a generalization of > single, double, triple, quadruple, quintuple, sextuple, sestuple, > octuple, etc. A tuple is a data record with a fixed number of fields > with individual meaning. There is nothing about homogeneity of data type > in that definition. A triple of floats is legitimately a tuple when each > is a coordinate (the individual meanings). In other contexts, the same > triple might properly be a list (such as of heights of people > arbitrarily ordered). My understanding is that, in this context, it's not so much data types which are heterogeneous, but the semantic meaning of the data. For instance, a tuple containing (first_name, last_name, address) would be a "legitimate" tuple, but not a tuple containing (address, address, address), which, if we follow Guido's philosophy, ought to be represented as a list. Whether including the distinction in the language offers any practical benefit is questionable. [snip] > > This would tend to show that Guido's notion here was not particularly > > intuitive. > > The problem is that it *is* intuitive, on his part, and usually not well > explained rationally. Excellent point. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Help understanding the decisions *behind* python?
On Friday 31 July 2009 19:49:04 Raymond Hettinger wrote: > On Jul 20, 9:27 am, Phillip B Oldham wrote: > > Specifically the "differences" between lists and tuples have us > > confused and have caused many "discussions" in the office. We > > understand that lists are mutable and tuples are not, but we're a > > little lost as to why the two were kept separate from the start. They > > both perform a very similar job as far as we can tell. > > The underlying C code for the two is substantially the same. In terms > of code, tuples are in effect just immutable lists that have the > added > feature of being hashable (and therefore usable as dictionary keys or > elements of sets). > > Beyond the mutable/hashable distinction, there is an important > philosophical distinction articulated by Guido. He deems tuples > to be useful for struct like groupings of non-homogenous fields > and lists to be useful for sequences of homogenous data suitable > for looping. > > While nothing in the list/tuple code requires you to make that > distinction, > it is important because that philosophy pervades the language. If you > follow Guido's direction, you'll find that the various parts of the > language fit together better. Do otherwise and you'll be going > against > the grain. I might be wrong, but I get the impression that many people don't indeed "get it" and use tuples as static arrays and lists when the array needs to be dynamically resized. This is certainly how I use them as well. This would tend to show that Guido's notion here was not particularly intuitive. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
On Friday 31 July 2009 18:54:23 Tim Rowe wrote: > 2009/7/31 Steven D'Aprano : > > On Thu, 30 Jul 2009 18:47:04 +0100, Tim Rowe wrote: > >> That and the fact that I couldn't stop laughing for long enough to learn > >> any more when I read in the Pragmatic Programmer's Guide that "Ruby, > >> unlike less flexible languages, lets you alter the value of a constant." > >> Yep, as they say "Bug" = "Undocumented feature"! > > > > That's no different from Python's "constant by convention". We don't even > > get a compiler warning! > > We don't actually *declare* that something is constant and then have > that declaration ignored. Python doesn't lie to us, although (as in > any language) a programmer might. You could say that Ruby doesn't either, you just need to read the documentation. Ruby's unwritten motto is "flexibility über alles". In this regard, it is consistent (1). Not much is really bolted down in Ruby. You get encapsulation, but it's so easy to break that it's mostly symbolic. It's a language which gives great power to the programmer. Whether Ruby programmers handle this power responsibly is another debate. Cheers, Emm (1) I find Ruby to be pretty consistent in general, which is not always the case of Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
On Friday 31 July 2009 01:06:31 Robert Kern wrote: > On 2009-07-30 16:44, r wrote: > > On Jul 30, 4:29 pm, Emmanuel Surleau > > > > wrote: > >>> 1.) No need to use "()" to call a function with no arguments. > >>> Python --> "obj.m2().m3()" --ugly > >>>Ruby --> "obj.m1.m2.m3" -- sweeet! > >>> Man, i must admit i really like this, and your code will look so much > >>> cleaner. > >> > >> It has benefits - code does look better. It has also significant cons - > >> it is ambiguous. > >> For instance: > >> > >> a = b > >> > >> Is b a variable or a method called without parameter? > > > > Hello Emanuel, > > Again, who so ever names a method with such a non-descriptive name > > will get whats coming to him. And if you did for some reason use such > > a cryptic name as "b", do yourself (and everyone else) a favor and > > follow it with "()" to denote the method call. Remember when something > > is optional that means you have an option to use it OR not use it. > > I believe his point is that it is ambiguous to the compiler, not humans > reading the code. Actually, both. Use a variable you didn't initialize? This is what you get: NameError: undefined local variable or method `b' for main:Object from (irb):1 The compiler has no idea if b is a variable or a method. It also makes it very easy to shadow an existing method by declaring a variable of the same name, which is problematic. I suppose it is a side-effect of Ruby's Perl philosophical inheritance - except that Perl uses sigils to prefix its variables, negating this issue. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Confessions of a Python fanboy
> 1.) No need to use "()" to call a function with no arguments.
> Python --> "obj.m2().m3()" --ugly
> Ruby --> "obj.m1.m2.m3" -- sweeet!
> Man, i must admit i really like this, and your code will look so much
> cleaner.
It has benefits - code does look better. It has also significant cons - it is
ambiguous.
For instance:
a = b
Is b a variable or a method called without parameter?
> 2.) the .each method
> container.each{|localVar| block}
> This method can really cleanup some ugly for loops, although i really
> like the readability of for loops.
It's not only the 'each' method. It's "anonymous callbacks everywhere", which
is pretty cool. Certainly one of my favourite features of Ruby.
> 3.) true OOP
> Now before you go and get all "huffy" over this statement, hear me
> out. Python is the best language in the world. But it damn sure has
> some warts! "len(this)" instead of "obj.length" max(that) instead of
> [1,2,3,4,5].max(). You know what i am talking about here people. We
> all get complacent and It seems easier to just cope with these
> problems instead of fighting for change.
While ob.length() is more clear to read, it follows the same "operator" logic
as __iter__. Which is OK, I suppose.
> But look at the French, WHAT
> THE HELL HAS THAT DONE FOR THEM, *NOTHING*
I assume this was supposed to be funny?
> As for the rest of Ruby, i am not impressed. The redundant usage of
> "end" over indention perplexes me.
You have the choice to use {}. If you are confused over languages which do not
use indentation to delimit code blocks, you should probably try out a few
languages outside Python.
> The Perlish feel of "require" and
> the horrifically cryptic idioms of Ruby regular expressions.
Cryptic idioms of Ruby regular expressions? They are Perl-like regular
expressions, not exactly a far cry from what re does. Also, you can chain
them, which is extremely nice.
> The "puts" and "gets" seem childish
Well, they're short and easy. Writing "gets" is more intuitive than using
raw_input()
> and the math class does not even have
> a degrees or radians function!
>
> Anyway, i thought i would get this off my chest and catch up with old
> friends in the meantime. We can all make Python the perfect language
> it needs to be, but it ain't gonna be easy!
> Thank you all
>
> PS stay tuned for more from this series
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: non-owning references?
On Friday 24 July 2009 17:14:06 you wrote: > Hrvoje Niksic writes: > > The term "variable" is used in the Python language reference and > > elsewhere > > Yes. It should also be abundantly clear from the constant stream of > confused newbies on this point that its usage of that term is different > to what many expect from usage elsewhere. > > > and is quite compatible with how other popular languages (Java, PHP, > > Lisp, ...) use it. Please stop complaining about valid terminology; it > > is not helpful. > > I disagree with your assertions. > > Rather than yet another round of this tedious debate, I merely point > interested readers to http://effbot.org/zone/python-objects.htm> > and ask them to draw their own conclusion on how compatible their > pre-existing “variable” concept is with Python's object reference > model. Then I must be one of these "confused newbies". After a cursory look at your article, I don't see a difference with Java variables (as long as we speak about non-primitive types). Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: len() should always return something
On Sunday 26 July 2009 00:42:26 Marcus Wanner wrote: > On 7/25/2009 10:08 AM, Piet van Oostrum wrote: > >> Steven D'Aprano (SD) wrote: > >> > >> SD> Ambiguity essentially boils down to being unable to reasonably > >> predict SD> the expectation of the coder. I say "reasonably", because if > >> you allow SD> unreasonable situations, everything is "ambiguous": > > > > That's for me the reason that len(42) is ambiguous. The OP apparently > > had 1 as expectation, whereas my first thought was the minimal number of > > bits to represent the number and 7.5 million came later :=). The number > > of bits I certainly find reasonable, and I would find the number of > > decimal digits equally reasonable. More so than 1, actually. 1 as the > > length of an int doesn't give any information. > > Well, for my two cents, I will say that the number of binary bits or > decimal digits is certainly the most sensible return value, and that the > former is the most useful, because the latter can be got with > len(str(42)). However, the former can also be (/slightly/ less)easily > got with len(bin(42))-2... For my two eurocents, I'd expect such an operator to be called "sizeof" and when applied to a collection, to also return the number of bits it uses. I don't think a 'len' function has meaning when applied to something else than a collection, really... > I also think that "Explicit is better than implicit." says that there > should be no return value in this case, as any return value would be > implicit. Agreed. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a maximum size to a Python program?
On Monday 27 April 2009 05:01:22 Carbon Man wrote: > I have a program that is generated from a generic process. It's job is to > check to see whether records (replicated from another system) exist in a > local table, and if it doesn't, to add them. I have 1 of these programs for > every table in the database. Everything works well until I do the postcode > table. The generated code is 5MB for a system with no current data. > Normally the file would not be this big as only the changes are copied > over. Python just quits, I have tried stepping through the code in the > debugger but it doesn't even start. > I am thinking that dynamically generating the programs to run might not be > such a good idea. It would be a shame to drop it because the system needs > to be generic and it runs from an XML file so the resulting code could be > pretty complex, and I am new to Python. The program did generate a pyc so > it was able to compile. > Thoughts anyone? I agree with what most people here have said: don't generate Python code, it's a bad idea. Put your data in CSV files instead (one per table, named after the table, for instantce). You might want to either have a separate file with metadata (column names, etc...) or have the first line be a header: "",""... "","",... "","",... Then use the csv module (in the standard library) to read the file. If your original data is in XML, you might want to parse it using lxml instead. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp mentality vs. Python mentality
On Saturday 25 April 2009 08:06:30 Carl Banks wrote: > In answering the recent question by Mark Tarver, I think I finally hit > on why Lisp programmers are the way they are (in particular, why they > are often so hostile to the "There should only be one obvious way to > do it" Zen). > > Say you put this task to a Lisp and a Python programmer: Come up with > a good, generic, reusable way to compare two lists. What are their > respective trains of thought? > > > Lisp programmer: > > Well, there is a standard function called mismatch that does it, but I > can't recommend it. First of all, you don't know where that > function's been. Anyone and their mother could have worked on it, did > they have good, sound programming practice in mind when they wrote > it? Of course not. Let's be real here, we have to implement this by > hand. > > (defun lists-are-equal (a b) >(or (and (not a) (not b)) >(and (= (car a) (car b)) (lists-are-equal (cdr a) (cdr b > > There, much better than the standard function, and better yet, it's in > the *absolute minimal form possible*. There is no way to express list > comparison in a more reduced form. It's almost erotic how awesome it > is. I'm---whoa, ok, I'm getting a little excited now, settle down. > Well, come to think of it, that's really not that good. First of all > it's a function. I mean, it just sits there and does nothing till you > call it. How boring is that? It can't react to the current > situation. Plus it compares all lists the same way, and that is > really inefficient. Every list compare is a new problem. Different > lists need different comparative strategies. This function simply > won't do. I need a macro that can intelligently compile the right > list compare methodology in. For instance, if we want to compare two > lists that are known at compile time, we don't want to waste time > comparing them at runtime. No, the macro must detect constant > arguments and special case them. Good start. Now, we have to > consider the conditions this comparison is being done under. If the > user is passing the result of a sort to this macro, it's almost > certain that they are trying to see whether the lists have the same > elements. We can do that a lot more efficiently with a countset. So > let's have the macro check to see if the forms passed to it are all > sort calls. Better yet, let's check for my own powerful sort macro. > Hmm. Wait... I think my 4600-line sort macro already checks its > calling context to see if its results are being fed to a list > comparison. I'll have to refactor that together with this macro. Ok, > good, now I am sure other users will eventually want to customize list > comparison for their own use, after all every list comparison is > different and I can't possibly anticipate all of them. A user needs > to be able to adapt to the situation, so it's vitally important to > create a plug-in infrastructure to give them that flexibility. Now, > what about exceptions, there's a millions ways to deal with that... > > ...and so on until eyelids can no longer stay open Ah well. I guess this explains Emacs. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
On Monday 20 April 2009 10:55:19 Steven D'Aprano wrote:
> On Mon, 20 Apr 2009 08:05:01 +0200, Emmanuel Surleau wrote:
> > On Monday 20 April 2009 01:48:04 Steven D'Aprano wrote:
> >> It also depends on whether you see the length of a data structure as a
> >> property of the data, or the result of an operation ("counting") on the
> >> data structure. We often fall into the trap of saying such things as
> >> "the string HAS A length of 42" when what we really mean is "if you
> >> count the elements of the string we find 42 of them". I don't believe
> >> that the relationship between strings and length is a has-a
> >> relationship. I believe it is a property requiring a function
> >> (counting) to emerge, and therefore under OO principles, length
should
> >> *not* be an attribute and Java et al are guilty of misuse of OO in
> >> making length an attribute.
> >
> > This didn't quite make sense. Methods are "abilities" an object has. Why
> > shouldn't a string be able to compute its length?
>
> Nothing. I'm not talking about methods, I'm talking about making length a
> property (or attribute if you prefer).
>
> I must admit a mistake: Java does not treat the length of a string as an
> attribute, but uses a callable method, String.length(), so I withdraw my
> accusation of misuse of OO principles.
Well, Java uses .length on arrays (but arrays are not really objects). But
most constants are hidden behind accessors or "regular" methods.
> [...]
>
> > As noted above, nothing would stop Fred from having the ability to
> > "computeHeight()", though. I guess you could say that what I find silly
> > is that String objects have a number of abilities, which: - are more
> > complicated than retrieving their own length - most likely use len()
> > internally anyway
>
> Advantages of calling a length method:
>
> - Consistency with other methods.
>
> - Makes it easy to discover by introspection.
>
> Disadvantages of calling a length method:
>
> - In Python for built-in lists, tuples and strings, it requires at least
> one extra attribute lookup that the len() function doesn't need. (Java
> can avoid paying that cost at runtime by doing it at compile time -- this
> isn't available to Python.)
Someone on the list pointed out that that Python actually stores the length of
a string in a field for performance reasons. I wouldn't be surprised to hear
that the same is true for lists and tuples. Thoughts?
> - It makes it more difficult to write functional code such as this:
>
> map(len, [seq1, seq2, seq3])
>
> where the various seq* are arbitrary sequences, not necessarily just
> strings. (Functional in the sense of functional-programming, not in the
> sense of "it works".)
That's a good point.
> - It makes it harder to intercept calls to len() for debugging. I can do
> this:
>
> def len(obj):
> print "called len with arg %r" % obj # or log it somewhere
> return __builtins__.len(obj)
>
> and have all the calls to len go through that, without even knowing what
> type of object is being called.
>
> But note that because len() in turn calls obj.__len__ (unless obj is a
> known built-in like str), you keep all the advantages of OO methods like
> sub-classing, without any of the disadvantages.
Both arguments hold true for any method, though.
> > And yet, when asked, it's not able to do something as basic as tell its
> > length. This seems inconsistent to me.
>
> Well, you can do this:
> >>> s = "abc"
> >>> s.__len__()
>
> 3
>
>
> but if you do it in public, be prepared to have other Python programmers
> laugh at you.
I do understand that you don't call __xxx__ without a good reason.
> It's just a stylistic difference, it's not a functional difference. Even
> if there is a genuine, objective advantage to one approach over the other
> (and I believe that advantage goes to len() as a function), it's quite
> small and it won't really make that big a difference.
Well, Aahz and Carl Banks managed to convince me that len() has legitimate
reasons to exist, and I can live with that. Thanks for providing some
examples of functional code where len() as a function is more interesting
than len() as a method.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
> >Allowing for procedural-style programming does not mean that a language > >does not implement (even imperfectly) an OO paradigm. > > "Allowing" is the wrong term here. Python absolutely encourages a > straightforward procedural style when appropriate; unlike Java, there is > no attempt to force object orientation everywhere. Appealing to Python's > "object-oriented" nature when arguing about design decisions and ignoring > the other programming styles it supports is an indicator that you don't > really know Python very well. I don't pretend to :) > Also, my code sample was itself a trick question. Python has *dynamic* > object orientation (just as the blurb says), and square() will work > on any object with a __mul__() method (through the ``*`` syntax), just as > len() works on any object with a __len__() method. So my code > demonstrates the way Python's programming styles interleave with each > other (throw in a listcomp to complete the set). This is what Carl Banks was saying below (that getting the length of something was generic operation)... Well, I suppose it sorts of make sense. I had the feeling that Python had been moving from a more procedural kind of language to a more object-oriented one (by having the "everything be an object"). But I'm beginning the see the logic in having a len() function (as opposed to a design wart). Thank you, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
On Monday 20 April 2009 01:48:04 Steven D'Aprano wrote:
> The problem is, I believe, that people wrongly imagine that there is One
> True Way of a language being "object-oriented", and worse, that the OTW
> is the way Java does it. (If it were Smalltalk, they'd at least be able
> to make the argument that Smalltalk invented the perfect OO language
and
> every change since then was corruption.) This is of course nonsense, but
> many people fall for it. "The way I'm used to is the One True Way".
>
> As far as str.len versus len(str), apart from saving one character, I
> don't see any advantage to one over the other. It really depends on what
> you're used to.
>
> It also depends on whether you see the length of a data structure as a
> property of the data, or the result of an operation ("counting") on the
> data structure. We often fall into the trap of saying such things as "the
> string HAS A length of 42" when what we really mean is "if you count the
> elements of the string we find 42 of them". I don't believe that the
> relationship between strings and length is a has-a relationship. I
> believe it is a property requiring a function (counting) to emerge, and
> therefore under OO principles, length should *not* be an attribute and
> Java et al are guilty of misuse of OO in making length an attribute.
This didn't quite make sense. Methods are "abilities" an object has. Why
shouldn't a string be able to compute its length?
> If you don't agree, consider an analogy: think about what it means to say
> that "Fred has a height", compared to "Fred has a left arm". You can
> point to Fred's left arm, you can surgically remove it, in principle at
> least you could surgically attach a left arm to somebody who didn't have
> one. The relationship between "Fred" and "left arm" is most certainly a
> "has-a" relationship. But the same isn't true for height: you can't
> surgically remove Fred's height, and you can't even point to the part of
> Fred that is his height. The length of a string is like height.
As noted above, nothing would stop Fred from having the ability to
"computeHeight()", though. I guess you could say that what I find silly is that
String objects have a number of abilities, which:
- are more complicated than retrieving their own length
- most likely use len() internally anyway
And yet, when asked, it's not able to do something as basic as tell its
length. This seems inconsistent to me.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
> What makes you think Python is "an OO language"? Python is a dynamic object-oriented programming language that can be used for many kinds of software development. First line on the Python official website. Was this a trick question? > What kind of OO > language allows you to do this: > > def square(x): > return x*x > > for i in range(10): > print square(x) Ruby, for instance. Allowing for procedural-style programming does not mean that a language does not implement (even imperfectly) an OO paradigm. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
On Sunday 19 April 2009 21:46:46 Christian Heimes wrote:
> Emmanuel Surleau wrote:
> > First off, it's pretty commonplace in OO languages. Secondly, given the
> > number of methods available for the string objects, it is only natural to
> > assume that dir("a") would show me a len() or length() or size() method.
> > Having to use a function for such a mundane operation feels unnatural
and
> > not OO.
>
> If you replace the term "OO" with "Java" in your posting, then I'm going
> to agree with you. Neither Java nor Python are pure object oriented
> languages. A while ago a friend of mine called Java a class centric
> programming language. I think that describes Java's coding philosophy
> very good. Python has a different coding philosphy. You can't assume
> that Java style development works with Python (and vice versa).
I don't know if it's "Java-style development" - you use a method to retrieve
the length of a string in C++, Ruby or Javascript. Are you trying to say that
having len() as a method/property is not object-oriented? The FAQ link in
Gabriel Genellina's posting justifies the existence "len as a function" as
historical. It does not seem to serve much purpose now. If there is a deeper
reason why "len as a function" makes more sense than "len as a method",
I'd be (genuinely) curious to hear it.
> Now to your rant about len(). Python class may implement several
> protocols with magic methods like __len__(), __iter__() or
> __getitem__(). The magic methods start and begin with two _. When a
> method implements the __len__() method then it supports len(). In Python
> readability counts. Try "import this" in a Python shell.
Not trying to attack you, but I'm not sure of what you're trying to say here.
That len("a") is more readable than "a".len()?
> PEP 8 is a coding guideline for the standard library. It's not a law.
> Some modules are older than the PEP, other modules and libraries were
> developed outside the core and added later. We had a long discussion
> about PEP8'ing more code but eventually we decided against it. More
> chances would break too much 3rd party code.
I was not suggesting breaking. What's wrong with aliasing and marking as
deprecated?
Also, given that Python 3000 breaks backward compatibility anyway, I don't
see the point in not cleaning up the standard library completely and get rid
of CamelCase once and for all.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
> Perhaps in statically typed languages. Python is dynamic, so a x.length()
> requires a method lookup and that's expensive. len(x) on the contrary, can
> be optimized on a case by case basis -- it DOESN'T translate to
> x.__len__() as some might think.
> See
> http://www.python.org/doc/faq/general/#why-does-python-use-methods-
for-some
>-functionality-e-g-list-index-but-functions-for-other-e-g-len-list
I don't know... the gist of the FAQ you link to is "that's legacy code and we
don't want to change it in order not to break code". It doesn't try to justify
the continued existence of len() and friends with technical arguments. I'll
grant you that avoiding a method lookup is cheaper, another question is
whether the difference would be noticeable in practice. I'd say that if
methods were such a bad thing, that would put in question the
implementation of the whole OO paradigm in Python, no?
> On a side note, there is an alternative to dir(), more human-friendly:
> http://inky.github.com/see/
>
> py> see("a")
>? [] in + * % < <= == != > >= len()
> .capitalize()
>.center() .count() .decode() .encode() .endswith()
> .expandtabs()
>.find() .format() .index() .isalnum() .isalpha() .isdigit()
>.islower() .isspace() .istitle() .isupper() .join() .ljust()
>.lower() .lstrip() .partition() .replace() .rfind() .rindex()
>.rjust() .rpartition() .rsplit() .rstrip() .split()
> .splitlines()
>.startswith() .strip() .swapcase() .title() .translate()
> .upper()
>.zfill()
>
> You can see len() there.
Nice! That's indeed more readable than dir().
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
Re: The Python standard library and PEP8
On Sunday 19 April 2009 19:37:59 Gabriel Genellina wrote:
> En Sun, 19 Apr 2009 13:43:10 -0300, Emmanuel Surleau
>
> escribió:
> > Exploring the Python standard library, I was surprised to see that
> > several
> > packages (ConfigParser, logging...) use mixed case for methods all over
> > the
> > place. I assume that they were written back when the Python styling
> > guidelines were not well-defined.
>
> The name policy changed in March 2004. Before that, PEP8 said:
>
> Function Names
>
>Plain functions exported by a module can either use the CapWords
>style or lowercase (or lower_case_with_underscores). There is
>no strong preference, but it seems that the CapWords style is
>used for functions that provide major functionality
>(e.g. nstools.WorldOpen()), while lowercase is used more for
>"utility" functions (e.g. pathhack.kos_root()).
>
> The current version says:
>
> Function Names
>
>Function names should be lowercase, with words separated by
> underscores
>as necessary to improve readability.
>
>mixedCase is allowed only in contexts where that's already the
>prevailing style (e.g. threading.py), to retain backwards
> compatibility.
Ah, that makes sense.
> > Given that it's rather irritating (not to mention violating the
> > principle of
> > least surprise) to have this inconsistency, wouldn't it make sense to
> > clean
> > up the API by marking old-style, mixed-case methods as deprecated (but
> > keep them around anyway) and add equivalent methods following the
> > lowercase_with_underscores convention?
>
> The threading module has such aliases, but there are no plans for mass
> renaming all the stdlib that I know of. You'll have to live with this
> inconsistency.
Damn.
> > On an unrelated note, it would be *really* nice to have a length
> > property on
> > strings. Even Java has that!
> Why would it be nice to have? I never missed it...
First off, it's pretty commonplace in OO languages. Secondly, given the
number of methods available for the string objects, it is only natural to
assume that dir("a") would show me a len() or length() or size() method.
Having to use a function for such a mundane operation feels unnatural and
not OO.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
The Python standard library and PEP8
Hi there, Exploring the Python standard library, I was surprised to see that several packages (ConfigParser, logging...) use mixed case for methods all over the place. I assume that they were written back when the Python styling guidelines were not well-defined. Given that it's rather irritating (not to mention violating the principle of least surprise) to have this inconsistency, wouldn't it make sense to clean up the API by marking old-style, mixed-case methods as deprecated (but keep them around anyway) and add equivalent methods following the lowercase_with_underscores convention? On an unrelated note, it would be *really* nice to have a length property on strings. Even Java has that! Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python after a few years of Ruby
Hi there, Ruby transfuge too. > Although I'm not 100% new to Python, most of my experience using high- > level languages is with Ruby. I had a job doing Rails web development > a little ways back and I really enjoyed it. At my current workplace > though, we're looking at using Python and I'm trying to get back into > the Python "groove" as it were. > > I've got plenty of materials to get me up to speed on the mechanics of > the language, but I was wondering about the equivalent of some tools I > was used to using in Ruby. If there's not anything that's a one-to-one > equivalent I totally understand, I'm just looking for some pointers > here to get me started. :) > > 1) Rake - is there an equivalent of Rake? I've seen a bit about SCons, > and it looks really nice, but it seems geared towards being a Make > replacement for C/C++ rather than something that's used to work with > Python itself. Is there anything like a Python build tool? (Or do I > even need something like that? I haven't worked with any large Python > systems, just little things here and there.) Zed Shaw (of Mongrel fame) apparently created a pythonic rake called Vellum. However, the website returns a 404, and the egg doesn't seem to work. Shame. > 2) Gems - I've seen a bit about Eggs, but they don't seem to have > anywhere near the official status gems do for Ruby. Are there any > "package management" things like this for Python, or do you usually > just grab the code you need as-is? Eggs looks like gems. Except that some of them have actual documentation. The Egg index is here: http://pypi.python.org/pypi. But I'll grant you that easy_install doesn't have quite the list of options gem has. > 3) Web frameworks - yeah, I realize there are tons of these, but are > TurboGears, Django, and Zope still the big ones? I've seen a lot about > Pylons, is that a separate framework or is it a ... well, frame that > other things are built on? (TG seems to be related to Pylons at a > glance?) Django is kind of like the Rails of Python, while Pylons is kind of like Merb (it integrates different frameworks to get the job done). > 4) Unit Test frameworks - If there's a behavioral test suite like > RSpec that's be awesome, but I'd be happy to settle for a good, solid > unit testing system. BDD doesn't seem to be a big focus of the Python community. No Cucumber either :(. Have a look at Nose, it looks decent. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python after a few years of Ruby
Hi > > 1) Is there anything like a Python build tool? (Or do I > > even need something like that?) > > If you're going to run the python source code, you don't need anything. > Python builds what it needs automagically. Some tools exist to build > stand-alone executables though, if you'd like to do so (e.g. py2exe, > http://www.py2exe.org) That's not what the gentleman is looking for. Rake is a ruby version of make. It lets you run tasks with dependencies. You use this for repetitive tasks, administration, etc. Very convenient. > > 3) Web frameworks > > I quite like the powerful and very intuitive and easy to use web2py > (http://www.web2py.com). > > (not to be confused with the minimalist web framework web.py, > http://webpy.org). Looks interesting. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI Programming
Howdy, > I'm python newbie and i need to write gui for my school work in python. > I need to write it really quick, because i haven't much time .) > So question is, which of gui toolkits should i pick and learn? I heard > PyGTK and Glade are best for quick gui programming? Is it good for > beginner? Or is there something better? > I have some experience with java swing, btw.. You might want to have a look at PyQt4 (http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/pyqt4ref.html) if you don't want something "ugly" (native look on all platforms). Also, it has excellent documentation. You can use Qt Designer with it, additionally. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Definition of Pythonic?
On Saturday 11 April 2009 18:00:58 John Yeung wrote: > On Apr 11, 10:08 am, Emmanuel Surleau > > wrote: > > Having written a few trivial scripts in Python, I'm curious as > > to how you would sum up the Pythonic philosophy of development. > > A couple of others have already mentioned the Zen of Python, available > at the Python command prompt. I would agree with that, but also add > the caveat that none of the principles expressed there are hard-and- > fast rules. Hopefully that is clear from the quasi-contradictory > nature of the principles, but inevitably there will be some people who > complain that Python breaks this or that "rule" from the Zen. Thank you all for the nice and prompt replies to what is a typical newbie question, which is bound to come back regularly. And no, you can't make everybody happy, per definition. > The fact is, it's impossible to satisfy every principle in every > situation. To me, Python distinguishes itself for how well it > balances all of them. "Compromise" is a word that comes up a lot when > talking about the design of Python. To some, that has a negative > connotation; to me, it's an inevitable consequence of being practical. That's fine with me: after all, you can't do software engineering without trade-offs. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Definition of Pythonic?
Hi there, I'm starting an exploratory foray into Python, being generally dissatisfied with the Ruby ecosystem (while the language is wonderful, third party libraries and documentation are not). Having written a few trivial scripts in Python, I'm curious as to how you would sum up the Pythonic philosophy of development. Judging from Python, it seems to exclude (mostly) "magical" variables like '$.'. Is this right? What else would you include in this definition? Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing dynamic languages
On Saturday 04 April 2009 15:37:44 grkunt...@gmail.com wrote:
> I am a Java developer. There, I said it :-).
>
> When I am writing code, I can rely on the compiler to confirm that
> any methods I write will be called with parameters of the "right"
> type. I do not need to test that parameter #1 really is a String
> before I call some method on it that only works on Strings.
>
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
Well, it depends on what you're trying to do, really. You do *not* want to
check parameters in every function. If you are designing a library, it is
strongly advised to document what kind of parameters your functions
expect. Otherwise, if your program will handle arbitrary input, you should
check its format and reject it if it's invalid.
Cheers,
Emm
--
http://mail.python.org/mailman/listinfo/python-list
