On Tuesday, November 12, 2013 2:06:09 AM UTC, Rick Johnson wrote:
>
>
>
> Justifying Global Variables:
>
>
>
> Globals are justified when they are used to communicate
>
>
On Tuesday, November 12, 2013 3:05:25 PM UTC, Rick Johnson wrote:
>
>
>
> When i type "math.pi", i "feel" as though i'm accessing an
>
> interface, BUT I'M NOT!
I'm not sure where you get the feeling you're accessing an interface. If I
typed this, I would feel like I was trying to change a f
On Tuesday, November 12, 2013 5:00:37 PM UTC, Rick Johnson wrote:
>
>
>1. Accept that globals are useful, and make them
>
> available through a "real" global syntax, not
>
> some attribute of a module that "appears" to be
>
> local, but in reality is global. Then prevent
act interfaces are key components in the style of building software they
> propose, in good company with TDD.
>
> Thx!
Late to the party, but I have added a package `jute` to PyPI which provides
interface checking closer to the model used in Java (and other compiled OO
languages). See
The language D has a feature called Uniform Function Call Syntax, which allows
instance methods to be resolved using function calls.
In Python terms, the call:
x.len()
would first check if 'x' has a method 'len', and would then look for a function
'len', passing 'x' as the first argument.
The
Thanks for the extensive feedback. Here's my thoughts on how to address these
issues.
On Saturday, 7 June 2014 20:20:48 UTC+1, Ian wrote:
>
> It's a nice feature in a statically typed language, but I'm not sure
> how well it would work in a language as dynamic as Python. There are
> some ques
On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote:
>
> Also it doesn't sit well with Python's "one obvious
> way to do it" guideline, because it means there are
> *two* equally obvious ways to call a function.
This provides a way to do something new (add class-optimized implementations
On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote:
>
> Also it doesn't sit well with Python's "one obvious
> way to do it" guideline, because it means there are
> *two* equally obvious ways to call a function.
Actually, one of the best arguments against introducing UFCS is that Python
On Sunday, 8 June 2014 15:59:14 UTC+1, Roy Smith wrote:
> Why? I assume a language which promoted the global namespace to be in
> the attribute search path (which, as far as I can tell, is what we're
> talking about here) would implement hasattr and raising AttributeError
> in a consistent w
On Sunday, 8 June 2014 13:06:08 UTC+1, Paul Sokolovsky wrote:
>
> Getting x.foo() to call foo(x) is what's bigger problem, which has
> serious performance and scoping confusion implications, as discussed in
> other mails.
The performance hit will only occur when the attribute access is about to
On Sunday, 8 June 2014 17:24:56 UTC+1, jongiddy wrote:
> # would work with UFCS
> f.readlines().map(int).min(key=lambda n: n %
> 10).str().b64encode(b'?-').print()
Ooops - map is the wrong way round to support UFCS in this case. However, with
UFCS, I could fix this by
On Sunday, 8 June 2014 18:24:28 UTC+1, Ian wrote:
>
> But that would all be done in getattr, so I don't think it affects
> hasattr's implementation at all. Since hasattr doesn't push anything
> onto the stack, getattr doesn't have to care whether it was called
> directly from Python or indirectl
On Monday, 9 June 2014 04:44:22 UTC+1, Chris Angelico wrote:
> This could be solved, though, by having a completely different symbol
> that means "the thing on my left is actually the first positional
> parameter in the function call on my right", such as in your example:
>
> > plus(1, 2) | divid
So, just to summarise the discussion:
There was some very mild support for readable pipelines, either using UFCS or
an alternative syntax, but the Pythonic way to make combinations of function
and method applications readable is to assign to variables over multiple lines.
Make the code read do
14 matches
Mail list logo
