Disqus - Friends of evangineer

Re: Am I Bored With “Web 2.0”?

tav — Mon, 23 Jun 2008 08:50:08 -0000

If you are bored with Web 2.0, perhaps I can interest you in Web 4.0 -- a Web 4 the people by the people ;p

Jokes aside, it really is needed. As Umair and you point out, the potential of the Web needs to be focussed upon the *real* problems that we all face.

Re: Migrating Disqus to a new domain

tav — Sat, 27 Sep 2008 00:50:51 -0000

Btw, I used the tav.espians.com url above as I can set it up to be a true permalink as opposed to the various googlecode.com urls -- which are likely to change with time.

--
Thanks again, tav

Re: Touch Society

tav — Tue, 28 Oct 2008 23:17:41 -0000

Hello Sofia!

Re: F.I.A.S.C.O. 2008 — Confessions of an Autodidactic Evangineer

tav — Sat, 08 Nov 2008 18:07:51 -0000

I agree that reform of the credit rating agencies are very much needed. But, as we've spoken before, I wonder whether less regulation wouldn't have more of a positive impact.

The real fundamental problem here isn't regulation, but transparency and understanding. The problem with the unfortunate "widow and orphans" in your example above is that they weren't able to get some proper second opinions.

Punters get ripped off every day and in every sector, despite high levels of regulation...

Would you agree that transparency would be a better solution than regulation?

Re: Video – Taleb and Mandebrot on the Credit Crunch — Confessions of an Autodidactic Evangineer

tav — Sat, 08 Nov 2008 18:08:38 -0000

Nice video -- we should get in touch with those two!

Re: How's longurlplease doing so far?

tav — Mon, 19 Jan 2009 19:03:33 -0000

Thanks for longurlplease. I plan on incorporating it (via the API) in a bookmarklet for Twitter.

Please let me know @tav if that would be okay -- don't want to cost you a lot of money if the bookmarklet becomes popular at all...

Thanks!

Re: git ready » piecemeal staging

tav — Tue, 20 Jan 2009 20:48:57 -0000

Not sure if you guys understand what "no pun intended" actually means... but, great tips!!

Please keep them coming. Whilst the git man pages are nice, it's much easier to discover useful features through practical tips like yours. Thanks!

Re: A Challenge To Break Python Security

tav — Mon, 23 Feb 2009 18:24:04 -0000

Still, very nice try _Mark_ -- would be interested to know when you get some contents into that file =)

Re: A Challenge To Break Python Security

tav — Mon, 23 Feb 2009 20:27:13 -0000

Yup!

And once we've got a comprehensive list of known exploits, work can finally begin on that front.

Re: A Challenge To Break Python Security

tav — Tue, 24 Feb 2009 04:33:56 -0000

@Anon

Yeah, I had the same problem with Blogger -- its captcha service was buggered in Firefox -- even when trying to post as a Blogger user. I tried with Safari and it worked fine...

As for removing ``compile``, I'd really be interested to know your thoughts/justification... it is the approach that I've currently gone for [since it was the simplest to implement] -- but I am not totally sure about it.

If someone can somehow get at a Code object, then they can still exploit it. I'm looking through the Python source code to see where else code objects are returned from -- the obvious places like FunctionType.func_code and GeneratorType.gi_code have already been removed... would be good to know for sure =)

Re: A Challenge To Break Python Security

tav — Tue, 24 Feb 2009 14:04:59 -0000

Have you seen Paul Cannon's exploit?

He constructed a nifty function with custom bytecode which was able to grab traceback objects off of the
stack...

I summarised it in this post to Python-Dev: http://mail.python.org/pipe...

Paul has also written a detailed blog post on: http://thepaulprog.blogspot...

Re: TweetFight -- Fight Club 2.0

tav — Tue, 03 Mar 2009 11:53:53 -0000

Yup, that will definitely be the most difficult aspect. But the internet is full of great fights -- check out YouTube or open source dev lists...

I'm predicting slow and steady uptake for this -- the most valuable thing it does is provides an easy way of capturing a conversation between two people.

Re: Paving the Way to Securing the Python Interpreter

tav — Tue, 03 Mar 2009 11:59:34 -0000

Thanks Marius. Yes, this is dealing with a related but separate problem altogether.

For that, as I state at the start of the article, I'd recommend looking at PyPy's sandboxed interpreter -- http://codespeak.net/pypy/d... -- or Google's open source NaCl (Native Client) sandboxing/virtualisation technology: http://code.google.com/p/na...

Re: Hello World

tav — Sun, 08 Mar 2009 12:59:38 -0000

Welcome to GitHub! What kind of open source projects are you working on? ;p

Re: Ruby-style Blocks in Python

tav — Sun, 08 Mar 2009 13:22:17 -0000

You have a point with the mixed use of tuples -- but unfortunately the syntax of yield expressions works against us on that =(

As for a decorator, yes, we could do a do() decorator, I could code one up if it would help make the case better...

Re: Ruby-style Blocks in Python

tav — Sun, 08 Mar 2009 13:26:58 -0000

Tom, it simply makes life easier.

I believe it could be similarly popular in the same way that @decorators have been tremendously popular despite just saving a few bytes.

Ruby has already proven the merits of a block syntax -- check out Rake and Rails for examples of how blocks are used to increase productivity!

Re: Ruby-style Blocks in Python

tav — Sun, 08 Mar 2009 13:32:57 -0000

Steven, you have a point with GOTOs and XML-as-config... *shudder*

But Ruby has shown that anonymous blocks can be used to improve the elegance of the code as well as increase the productivity of the developer.

As for testing, I don't see why such an approach precludes either testing or documentation.

In fact, it could make testing more pleasant than the java-inspired unittest framework we currently have.

See this http://blog.excastle.com/20... for

CheckThrows(EInvalidOperation) do
DoSomething
end

I can even see interesting ways that __do__ could be used to create nice doctests.

Re: Ruby-style Blocks in Python

tav — Sun, 08 Mar 2009 13:34:34 -0000

I'll try to find a better replacement for ``with``...

Suggestions from everyone very welcome!

Re: Ruby-style Blocks in Python

tav — Sun, 08 Mar 2009 13:43:17 -0000

@thebitguru this wouldn't be faster in terms of performance for the default case but will save the explicit creation of the local function as you point out

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:34:06 -0000

Thanks Todd! That fits the bill quite nicely -- despite being slightly longer to type...

Will update this proposal now.

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:47:57 -0000

Thanks sjs, perhaps an accompanying decorator would help too?

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:55:47 -0000

Thanks for catching the mistake Mark -- fixed.

I agree that {} and shorter code would be better. Unfortunately I haven't been able to come with a Pythonic way of doing that.

This proposal was about trying to come with a Pythonic equivalent.

As for a better language, I agree -- and perhaps I should just do that -- there would be a lot less resistance! =)

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:57:26 -0000

Thanks Joeri -- fixed.

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 11:41:53 -0000

Multi-line lambdas would be nice, but one step at a time =)

And thanks for the blog article!

Re: Update on Securing the Python Interpreter

tav — Wed, 11 Mar 2009 10:11:34 -0000

Hey Mark,

Thank you for this!

Sorry that I missed the discussion on e-lang -- wasn't aware that a similar approach was being explored on there! I see both were inspired by Ka-Ping Yee's post years ago...

The Namespace function initially only supported the explicit:

Namespace(get_x=get_x, get_y=get_y)
Namespace(get_x, get_y) # using __name__

It still supports this format. But, as you rightly pointed out in that email, it quickly got tedious and I streamlined it ;p

By removing the implicit format the attack you show goes away... and we go back to a pure capability base. Perhaps we could start from there?

As for your concerns of efficiency in the email, in my C/Cython implementation of Namespace:

http://github.com/tav/plexn...

I use a trick from the PyPy guys and share the dictionary *keys* amongst the various Namespace objects. This is still nowhere near as efficient as Python classes, but it at least saves on memory -- which could be considerable when lots of similar Namespace objects are created.

And speaking of PyPy, I'm increasingly tending towards using it as a showcase:

* Fork the Python implementation on PyPy
* Add native support for object capability and some distributed features
* Bootstrap from that point and demonstrate the viability/utility of the ideas

We could perhaps even take a leaf from Allen Short's C implementation of E (ecru) where he builds it as an extension type for Python -- allowing it to be bootstrapped off existing Python libraries...

In an ideal case, the ideas would then get folded back into mainline Python -- but failing that, we would still have a Python-esque object-capability language that should be useful on its own...

What do you think of this?

--
Thanks again for taking the time to share your thoughts, tav