On Wednesday 18 Nov 2009 22:31:52 Shmuel Fomberg wrote:
> Hi Yosef.
>
> >> they (the python world) hate mini-languages, and prefer objects with a
> >> lot of methods.
> >> for example, instead of sprintf("%10s", ...) they have string.ljust
> >> method.
> >
> > however, you can do:
> > s = "Hello %s, I'm %d years old" % ("world!", 28)
> > where the % operator for strings does format-string substitution.
>
> I'm aware of this operator, and I'm also sure that it support the full C
> printf spec. (probably minus the weird cases)
> The point here is not of power - more of style. where in other languages
> we work with a cheat sheet for the printf format, in Python there are
> bunch of methods to do the same thing - just more readable.
>
I should also note that Python also supports named parameters to % if you pass
it a dictionary (= hash in Perl-speak) reference. Here is my CPAN module that
implements it for Perl (in user-land):
http://search.cpan.org/dist/Text-Sprintf-Named/
This is the closest I found for interpolation (e.g: "My name is $name , and I
am $age years old.") in Python, but naturally, it's a more verbose syntax
generally. Ruby has interpolation using "#{...}" which from what I understood
will be handled in a similar way to Perl 6's full-fledged expressions rather
than Perl 5's hacky interpolation heuristic.
> >> The closure mechanizem is pretty weak, and can be better describe as
> >> constants placing, and is reduced to one liner.
> >
> > This is what I remember about closures from perl, and I use closures in
> > Python for eveerything I did in Perl. What can you do with a perl
> > closure more than this?
>
> I tried to define in Python:
> def JumpingCounter(start):
> x = start;
> def func(jump):
> x = x + jump
> return x
> return func
>
> It failed to compile. the reason, as much as I see it, is because 'x'
> become a constant for func after JumpingCounter ended.
> In Perl, it would have worked. the captured variable stays a variable.
Interesting.
>
> I have been thinking about it a little, and as much as I can remember,
> every time I used closure in Perl, it was either a generator or a
> constant-closure. And most people have problems "getting" closures. so
> maybe it is not a bad idea to break this power tool to two weaker tools
> that are more focused.
I have used closures when I need them, and for a variety of tasks. I agree
that closure are a bit hard to grok, but they are a very powerful tool in the
hand of a capable programmer, and I'd prefer to keep them. They also allows
one to get rid of the context-parameter-for-a-callback anti-pattern (or what
the Subversion developers call baton in their codebase) that inhibits a lot of
ANSI C code:
<<<<<<<<<<<
avl_tree_create(tree, my_compare, context);
.
.
.
static my_compare(void * a_node, void * b_node, void * context)
{
.
.
.
}
>>>>>>>>>>
I should note that a relatively recent version of Python 2.x has added
something called "decorators":
http://wiki.python.org/moin/PythonDecorators
I attended a short presentation about them in one of the Python-IL meetings
and it went from something relatively easy to understand to being hard to
understand. Then towards the end the presenter said that one doesn't need
those decorators if they have closures.
> >> A weird thing about objects and inheritance: when calling a super's
> >> function, we can't call $self->SUPER::func(...) of like Moose super().
> >> (if I remember correctly) we call the super function by name.
> >> MyBase.func(self, ...).
> >
> > You have super() in Python, and it has one of those "considered harmful"
> > articles:
> > http://fuhm.net/super-harmful/
>
> hmmm. In Perl we have the SUPER metaclass, and IIRC it was "fixed" by
> the SUPER CPAN module, and Moose created their own super command.
> Problematic staff, it seen to be...
super() in Python returns an object which uses the same physical fields as the
object of the original class but believes it belongs to a super-class. Someone
I talked with on Jabber said he used that a lot in Python, but when I asked
people on #moose about it, they said that they think it was a very bad idea
and that there are better ways to achieve it. I still have the channel log.
>
> Another interesting subject is Tuples.
> Tuples are arrays, more like constant arrays.
> And I was very suprised to read that I can use them as hash keys. at
> first it sound weird, but then I remembered all the times that I have
> created string out of multiple values and used it as hash key.
>
Yes, in Perl the implementation details of the hash[Hash-Impl] leak to the
programmer. Don't know if and how Perl 6 will fix it. Of course, in Python
it's possible that looking up a hash by a number and by the equivalent string
will yield different results, because the hash keys are typed in Python.
{{{{{{{{
[Hash-Impl] - these implementation details are not specific to Perl - all
hashes must accept serialised keys by implementation, but some languages do
the serialisation for you.
}}}}}}}}
Regards,
Shlomi Fish
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Parody on "The Fountainhead" - http://shlom.in/towtf
Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
_______________________________________________
Perl mailing list
[email protected]
http://mail.perl.org.il/mailman/listinfo/perl
