101–108 of 108 posts
I guess I agree things could be simpler, although the cries of "garbage!" were a bit much. I wrote a wrapper function around urllib2 about 5 years ago and haven't looked back.
That's precisely the problem: your wrapper helps you...and only you (ie, it's worthless).
Earlier quoted context omitted.
I didn't find making moderately complex HTTP requests in Ruby to be much more fun than urllib2 in Python. Do you have a library you recommend?
I like httparty or mechanize, but feel free make your own choice over here https://www.ruby-toolbox.com/categories/http_clients
Earlier quoted context omitted.
The acid test is to see if you can avoid terms like "Writer", "Printer", and whether someone is able to explore your API using the REPL. >>> import log >>> log.log(log.CRITICAL, 'PrintModule', 'Printer failure', sys.exc_info()) PrintModule: Printer failure >>> print log.configuration [ ] >>> log.configuration.clear() >>> print log.configuration [] >>> def send_mail(level, module, message, exception): ... import smtpl…
Thanks. I like the idea of classes masquerading as functions. And easier configuration. I had actually started writing this 2 days ago as something just for me, but after reading this decided to try something new.
log.getLogger()
I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. If you have a look at the older libraries, most of them were written in a procedural style. Not only that, it is very amenable to testing in the REPL. import smtplib s=smtplib.SMTP("localhost") s.sendmail("me@my.org",tolist,msg) note the absence of…
I've been programming python for nearly 10 years, but your comment just helped me clarify a thought that I've had for ages but have never been able to put in to words before: a well designed Python API is one that can be effortless used within the REPL. And that's why urllb2 sucks.
I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. If you have a look at the older libraries, most of them were written in a procedural style. Not only that, it is very amenable to testing in the REPL. import smtplib s=smtplib.SMTP("localhost") s.sendmail("me@my.org",tolist,msg) note the absence of…
I've been programming python for nearly 10 years, but your comment just helped me clarify a thought that I've had for ages but have never been able to put in to words before: a well designed Python API is one that can be effortless used within the REPL. And that's why urllb2 sucks.
Earlier quoted context omitted.
Well, Perl's CPAN has an uninstall feature. That's kind of nice.
cpan is very much not a std lib. PyPi is equiv.
If you say a "std lib" is something that is installed along with the language, then CPAN fits the bill.
$ corelist CPAN
CPAN was first released with perl 5.004Earlier quoted context omitted.
cpan is very much not a std lib. PyPi is equiv.
Depends on what your definition of "std lib" is. If you say a "std lib" is something that is installed along with the language, then CPAN fits the bill. $ corelist CPAN CPAN was first released with perl 5.004
Even if CPAN was a standard library, that which you install from it is clearly not, which is what the argument to date has centered around.
Earlier quoted context omitted.
> If anyone remembers, Java had to do OO in a > big-style with OO everywhere -- there were no > alternatives. You can write Java that isn't heavily OO, but you have to implement alternatives to sections of the stdlib that most people assume or take for granted. Related to what you're saying about the GUI, I'd be interested to see a detailed summary of what the Lighthouse people did, and how it was different to Java.…
I've struggled through a few Cocoa tutorials. I think the programmer creates a delegate object which handles events. These delegates are assigned to UI elements, similar to how one would addMouseListener to a Java UI element. I may be entirely wrong here. Perhaps someone who knows can put the facts straight.
In Cocoa touch, it's:
[mybutton addTarget:someObjectMaybeSelf action:@selector(onClick) forControlEvents:UIControlEventTouchupInside];
The framework usually use delegates when a data source is needed. (for example to build up a table, you need to specify how many rows, what goes into each row etc).
Cocoa touch is really clean. Cocoa is still nice but a little messy.