You know what I find rich about all of this?
>>>[ ... ]> I'd like to change the syntax of my module 'codeblocks' to make it
>>>more
>>>[ ... ]> pythonic.
Kiuhnm posted a thread to the group asking us to help him make it more
Pythonic, but he has steadfastly refused every single piece of help he
On 05/04/2012 05:12 AM, Kiuhnm wrote:
>> Hand-wavy, no real example, doesn't make sense.
>
> Really? Then I don't know what would make sense to you.
Speaking as as an observer here, I've read your blog post, and looked at
your examples. They don't make sense to me either. They aren't real
examp
On Fri, May 4, 2012 at 9:12 PM, Kiuhnm
wrote:
> If I and my group of programmers devised a good and concise syntax and
> semantics to describe some applicative domain, then we would want to
> translate that into the language we use.
> Unfortunately, Python doesn't let you do that.
No, this is not
On 5/4/2012 4:44, alex23 wrote:
On May 4, 2:17 am, Kiuhnm wrote:
On 5/3/2012 2:20, alex23 wrote:
locals() is a dict. It's not injecting anything into func's scope
other than a dict so there's not going to be any name clashes. If you
don't want any of its content in your function's scope, just
alex23 writes:
> The examples here are a wonder to behold as well:
> http://mtomassoli.wordpress.com/2012/04/20/code-blocks-in-python/
Wow. “What really happens is that rewrite rewrites the code, executes it
and quits.”
Please keep this far away from anything resembling Python.
--
\ “I
On May 4, 1:47 pm, Steven D'Aprano wrote:
> I too am uncomfortable about passing locals() to a function, but not
> because of imaginary "name clashes". The problem as I see it is that this
> will give the function access to things the function has no need for.
And I would never use it in the real
On Fri, May 4, 2012 at 12:44 PM, alex23 wrote:
> On May 4, 2:17 am, Kiuhnm wrote:
>> I would've come up with something even better if only Python wasn't so rigid.
>
> The inability for people to add 6 billion mini-DSLs to solve any
> stupid problem _is a good thing_. It makes Python consistent an
On Thu, 03 May 2012 19:44:57 -0700, alex23 wrote:
[snip]
> My version was:
>
> def a(): pass
> def b(): pass
>
> func_packet = locals()
> func(arg, func_packet)
>
> Now, please explain how that produces name-clashes that your version
> does not.
I too am uncomfortable about pas
On May 4, 2:17 am, Kiuhnm wrote:
> On 5/3/2012 2:20, alex23 wrote:
> > locals() is a dict. It's not injecting anything into func's scope
> > other than a dict so there's not going to be any name clashes. If you
> > don't want any of its content in your function's scope, just don't use
> > that con
On Thu, May 3, 2012 at 10:17 AM, Kiuhnm
wrote:
> On 5/3/2012 2:20, alex23 wrote:
>>
>> On May 2, 8:52 pm, Kiuhnm wrote:
func(some_args, locals())
>>>
>>>
>>> I think that's very bad. It wouldn't be safe either. What about name
>>> clashing
>>
>>
>> locals() is a dict. It's not inje
> if only Python wasn't so rigid.
what.
You realize you'd have a little more luck with Python if you weren't
wielding it like a cudgel in the examples you've posted here, right?
Because it looks like you're treating the language as everything it
isn't and nothing it is this whole time. No wonder
On 5/3/2012 2:20, alex23 wrote:
On May 2, 8:52 pm, Kiuhnm wrote:
func(some_args, locals())
I think that's very bad. It wouldn't be safe either. What about name
clashing
locals() is a dict. It's not injecting anything into func's scope
other than a dict so there's not going to be any n
On 05/02/2012 10:26 PM, Michael Torrie wrote:
> If you are experiencing name clashes you need to start dividing your
> code up logically instead of keeping everything in the global namespace
> of your module.
I shouldn't have used the word "global" here as it's not actually global.
--
http://mai
On 05/02/2012 04:52 AM, Kiuhnm wrote:
> The problem is always the same. Those functions are defined at the
> module level so name clashing and many other problems are possible.
Only functions defined at the module level are in fact in the module's
namespace. For example, this works fine, and the
On May 2, 8:52 pm, Kiuhnm wrote:
>> func(some_args, locals())
>
> I think that's very bad. It wouldn't be safe either. What about name
> clashing
locals() is a dict. It's not injecting anything into func's scope
other than a dict so there's not going to be any name clashes. If you
don't want
Steven D'Aprano wrote:
> >> Have you actually tried to use these code blocks of yours? I asked you
> >> for a *working* example earlier, and you replied with examples that
> >> failed with multiple NameErrors and no hint as to how to fix them. And
> >> now you give an example that fails with Synta
On 02/05/2012 11:52, Kiuhnm wrote:
I remember a post on this ng when one would create a list of commands
and then use that list as a switch table. My module let you do that very
easily.
Kiuhnm
I'll believe that when I see a reference to your code repository and the
working example that others
On 5/2/2012 4:43, alex23 wrote:
[Apologies in advance if this comes through twice]
On May 2, 12:18 am, Kiuhnm wrote:
"Most Pythonic" doesn't mean better, unfortunately.
Nor does it mean "Kiuhnm prefers it".
That goes without saying.
For instance, assume that you want to write a function
On May 2, 12:18 am, Kiuhnm wrote:
> "Most Pythonic" doesn't mean better, unfortunately.
Neither does "Kiuhnm prefers it".
> For instance, assume that you want to write a function that accepts a
> dictionary of callbacks:
> func(some_args, callbacks)
>
> Pythonic way
>
>
> def whe
On May 2, 12:43 pm, alex23 wrote:
> I'm not entirely sure what your 'solution' offers over something like:
>
> class FOO(object):
> def __init__(self, fn):
> self.fn = fn
>
> def __enter__(self):
> return self.fn
>
> def __exit__(self, exc_type, exc_value, traceback):
>
[Apologies in advance if this comes through twice]
On May 2, 12:18 am, Kiuhnm wrote:
> "Most Pythonic" doesn't mean better, unfortunately.
Nor does it mean "Kiuhnm prefers it".
> For instance, assume that you want to write a function that accepts a
> dictionary of callbacks:
> func(some_args
Steven D'Aprano writes:
> On Tue, 01 May 2012 19:07:58 +0200, Kiuhnm wrote:
> > [entitled demands]
> Believe it or not, the world does not revolve around you. We cannot
> see what is in your head. If we ask for a WORKING EXAMPLE, you need to
> give an example that includes EVERYTHING necessary t
On Tue, 01 May 2012 19:07:58 +0200, Kiuhnm wrote:
> On 5/1/2012 17:11, Steven D'Aprano wrote:
>>> My way
>>> --
>>>
>>> with func(some_args)<< ':dict':
>>> with when_odd as 'n':
>>> pass
>>> with when_prime as 'n':
>>> pass
>>
>>
>> If you actually try that, yo
Arnaud Delobelle wrote:
On May 1, 2012 6:42 PM, "Jerry Hill" wrote:
On Tue, May 1, 2012 at 1:07 PM, Kiuhnm wrote:
If you had read the module's docstring you would know that the public
version uses
Are you aware that you've never posted a link to your module, nor it's
docstrings? Are you also
(sent from my phone)
On May 1, 2012 6:42 PM, "Jerry Hill" wrote:
>
> On Tue, May 1, 2012 at 1:07 PM, Kiuhnm
> wrote:
> > If you had read the module's docstring you would know that the public
> > version uses
>
> Are you aware that you've never posted a link to your module, nor it's
> docstrings?
On Tue, May 1, 2012 at 1:07 PM, Kiuhnm
wrote:
> If you had read the module's docstring you would know that the public
> version uses
Are you aware that you've never posted a link to your module, nor it's
docstrings? Are you also aware that your module is essentially
unfindable on google? Certai
Holy crap.
Easy there, tiger.
I understand you're frustrated, but the people here are trying to
help, even if they've decided the means of helping is trying to
explain why they feel your style of development isn't the best way to
do things.
You're going to wear out your welcome and not get any h
On 5/1/2012 17:11, Steven D'Aprano wrote:
My way
--
with func(some_args)<< ':dict':
with when_odd as 'n':
pass
with when_prime as 'n':
pass
If you actually try that, you will see that it cannot work. You get:
SyntaxError: can't assign to literal
If you
On Wed, May 2, 2012 at 1:11 AM, Steven D'Aprano
wrote:
> So in this case, even though Python is slightly more verbose, and forces
> you to have the discipline of writing named functions ahead of time, this
> is actually a *good* thing because it encourages you to test them.
>
> If the callbacks ar
On Tue, 01 May 2012 16:18:03 +0200, Kiuhnm wrote:
> "Most Pythonic" doesn't mean better, unfortunately.
Perhaps. But this example is not one of those cases.
> For instance, assume that you want to write a function that accepts a
> dictionary of callbacks:
>func(some_args, callbacks)
>
> Py
On Wed, May 2, 2012 at 12:18 AM, Kiuhnm
wrote:
> "Most Pythonic" doesn't mean better, unfortunately.
>
> For instance, assume that you want to write a function that accepts a
> dictionary of callbacks:
> func(some_args, callbacks)
>
> Pythonic way
>
>
> def when_odd(n):
> pass
>
>
On 5/1/2012 5:27, alex23 wrote:
On Apr 30, 2:05 am, Peter Pearson wrote:
Hey, guys, am I the only one here who can't even guess what
this code does? When did Python become so obscure?
Thankfully it hasn't. The most Pythonic way to pass around a code
block is still to use a function.
"Most
mwil...@the-wire.com writes:
> Another take-away might be don't use boilerplate, but in the situation
> I didn't see a simple way to avoid it.
It seems we agree, then, that avoiding boilerplate code is preferable to
writing bad boilerplate code.
--
\ “Computer perspective on Moore's L
Kiuhnm wrote:
> Regarding ctypes, try this to convince yourself that there's no problem
> in reusing BignumPtrType:
> from ctypes import POINTER, c_int
> assert POINTER(c_int) is POINTER(c_int)
print ('POINTERs are shareable:', ctypes.POINTER (BignumType) is ctypes.POINTER
(BignumType))
On 4/30/2012 17:42, mwil...@the-wire.com wrote:
On 4/30/2012 17:02, Kiuhnm wrote:
BignumTypePtr = ctypes.POINTER(BignumType)
for op, op_word in ((libbnem.BN_add, libbnem.BN_add_word),
(libbnem.BN_sub, libbnem.BN_sub_word)):
op.argtypes = [BignumTypePtr] * 3
op_word.argtypes = [BignumTypePtr, ct
> On 4/30/2012 17:02, Kiuhnm wrote:
>> BignumTypePtr = ctypes.POINTER(BignumType)
>>
>> for op, op_word in ((libbnem.BN_add, libbnem.BN_add_word),
>> (libbnem.BN_sub, libbnem.BN_sub_word)):
>> op.argtypes = [BignumTypePtr] * 3
>> op_word.argtypes = [BignumTypePtr, ctypes.c_ulong]
>> op.restype = op
On 4/30/2012 17:02, Kiuhnm wrote:
On 4/30/2012 16:17, mwil...@the-wire.com wrote:
Ben Finney wrote:
[ ... ] Even worse is the
penchant for ‘foo .bar()’, the space obscures the fact that this is
attribute access.
I like the style sometimes when it helps to break the significantly
different pa
On 4/30/2012 16:17, mwil...@the-wire.com wrote:
Ben Finney wrote:
[ ... ] Even worse is the
penchant for ‘foo .bar()’, the space obscures the fact that this is
attribute access.
I like the style sometimes when it helps to break the significantly different
parts out of
boilerplate:
libb
Ben Finney wrote:
> [ ... ] Even worse is the
> penchant for ‘foo .bar()’, the space obscures the fact that this is
> attribute access.
I like the style sometimes when it helps to break the significantly different
parts out of
boilerplate:
libbnem. BN_add .argtypes = [ctypes.POINTER (Bignu
Peter Pearson writes:
> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
> > I'd like to change the syntax of my module 'codeblocks' to make it
> > more pythonic.
The “chained callable” style isn't very Pythonic, IMO. Even worse is the
penchant for ‘foo .bar()’, the space obscures the fact th
29.04.12 19:05, Peter Pearson написав(ла):
Hey, guys, am I the only one here who can't even guess what
this code does? When did Python become so obscure?
This isn't Python at all. It's Ruby.
--
http://mail.python.org/mailman/listinfo/python-list
>> Current Syntax:
>>
>> with res << func(arg1) << 'x, y':
>> print(x, y)
>>
>> with res << func(arg1) << block_name << 'x, y':
>> print(x, y)
>>
>> New Syntax:
>>
>> with res == func(arg1) .taking_block (x, y):
>> print(x, y)
>>
>> with res == func(ar
On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
> I'd like to change the syntax of my module 'codeblocks' to make it more
> pythonic.
>
> Current Syntax:
>
> with res << func(arg1) << 'x, y':
> print(x, y)
>
> with res << func(arg1) << block_name << 'x, y':
> print(x
Kiuhnm wrote:
I'd like to change the syntax of my module 'codeblocks' to make it more
pythonic.
Current Syntax:
with res << func(arg1) << 'x, y':
print(x, y)
with res << func(arg1) << block_name << 'x, y':
print(x, y)
New Syntax:
with res == func(arg1) .taking_bl
On 4/27/2012 18:07, Steven D'Aprano wrote:
> On Fri, 27 Apr 2012 17:03:19 +0200, Kiuhnm wrote:
>
>> On 4/27/2012 16:09, Steven D'Aprano wrote:
>>> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
>>>
I'd like to change the syntax of my module 'codeblocks' to make it
more pythonic.
On Fri, Apr 27, 2012 at 10:07 AM, Steven D'Aprano
wrote:
> How about you give an actual working example of what you mean by a code
> block and how you use it?
He wrote a full blog post about it last week:
http://mtomassoli.wordpress.com/2012/04/20/code-blocks-in-python/
--
http://mail.python.or
On Fri, 27 Apr 2012 17:03:19 +0200, Kiuhnm wrote:
> On 4/27/2012 16:09, Steven D'Aprano wrote:
>> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
>>
>>> I'd like to change the syntax of my module 'codeblocks' to make it
>>> more pythonic.
>>>
>>> Current Syntax:
>>>
>>> with res << func(ar
On 4/27/2012 16:09, Steven D'Aprano wrote:
On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
I'd like to change the syntax of my module 'codeblocks' to make it more
pythonic.
Current Syntax:
with res << func(arg1) << 'x, y':
print(x, y)
with res << func(arg1) << block_n
On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
> I'd like to change the syntax of my module 'codeblocks' to make it more
> pythonic.
>
> Current Syntax:
>
> with res << func(arg1) << 'x, y':
> print(x, y)
>
> with res << func(arg1) << block_name << 'x, y':
> print
I'd like to change the syntax of my module 'codeblocks' to make it more
pythonic.
Current Syntax:
with res << func(arg1) << 'x, y':
print(x, y)
with res << func(arg1) << block_name << 'x, y':
print(x, y)
New Syntax:
with res == func(arg1) .taking_block (x, y):
50 matches
Mail list logo
