On Jan 3, 3:38 am, alex23 wrote:
> On Dec 27 2011, 8:01 pm, Eelco wrote:
>
> > But I consider it a reasonable change for a
> > 'python 4', or whatever the next major version change will be called.
>
> You do realise there were 8 years between 2 & 3? You might be waiting
> for quite some time.
Ye
On Jan 3, 3:39 pm, Rick Johnson wrote:
> It's NOT a fork Alex. It IS in fact the next logical step in Python's
> future evolution.
Link to the repo please, or STFU.
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 2, 8:38 pm, alex23 wrote:
> Conversely, you could pitch in behind Rick Johnson's Python 4000 fork,
> I sure it's progressing nicely given how long Rick has been talking it
> up.
It's NOT a fork Alex. It IS in fact the next logical step in Python's
future evolution.
--
http://mail.python.
On Dec 27 2011, 8:01 pm, Eelco wrote:
> But I consider it a reasonable change for a
> 'python 4', or whatever the next major version change will be called.
You do realise there were 8 years between 2 & 3? You might be waiting
for quite some time.
Conversely, you could pitch in behind Rick Johnso
On Fri, Dec 30, 2011 at 10:24 AM, Lie Ryan wrote:
> Another drawback of it is that it looks misleadingly similar to C++
> namespace notation.
Granted, but I don't see that as a drawback. The current notation is
just as similar to C's pointer-dereference notation, but that hasn't
led people to thi
On 12/30/2011 12:23 AM, Steven D'Aprano wrote:
On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
I would argue that the use of single special characters to signal a
relatively complex and uncommon construct is exactly what I am trying to
avoid with this proposal.
This would be the proposal to
On Dec 29, 2:23 pm, Steven D'Aprano wrote:
> On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
> > I would argue that the use of single special characters to signal a
> > relatively complex and uncommon construct is exactly what I am trying to
> > avoid with this proposal.
>
> This would be the pro
On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
> I would argue that the use of single special characters to signal a
> relatively complex and uncommon construct is exactly what I am trying to
> avoid with this proposal.
This would be the proposal to change the existing
head, *tail = sequen
On Dec 28, 11:29 pm, Lie Ryan wrote:
> On 12/28/2011 11:08 PM, Eelco wrote:
>
> > I personally feel any performance benefits are but a plus; they are
> > not the motivating factor for this idea. I simply like the added
> > verbosity and explicitness, thats the bottom line.
>
> Any performance bene
On 12/28/2011 11:08 PM, Eelco wrote:
I personally feel any performance benefits are but a plus; they are
not the motivating factor for this idea. I simply like the added
verbosity and explicitness, thats the bottom line.
Any performance benefits are a plus, I agree, as long as it doesn't make
On Dec 28, 12:07 am, Steven D'Aprano wrote:
> On Mon, 26 Dec 2011 13:51:50 -0800, Eelco wrote:
>
> [...]
>
> >> If your point is that parens are used more often than
> >> packing/unpacking, that's almost certainly true, since function calls
> >> (including method invocations) are so prevalent in p
On Dec 28, 8:08 am, Chris Angelico wrote:
> On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
>
>
>
>
>
>
>
>
>
> wrote:
> > On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
> >> ... suppose you have a huge
> >> set/frozenset using tuples as the keys, and one of your operations is to
>
On Dec 28, 2:11 am, Rick Johnson wrote:
> On Dec 27, 5:10 pm, Steven D'Aprano
> +comp.lang.pyt...@pearwood.info> wrote:
> > On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> > Your original use-case, where you want to change the type of tail from a
> > list to something else, is simply solved by
On Dec 27, 11:57 pm, Steven D'Aprano wrote:
> On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:
> > On Dec 25, 6:05 pm, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
>
> [...]
>
> >> > How is 'head, *tail = sequence' or semantically
On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
wrote:
> On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
>
>> ... suppose you have a huge
>> set/frozenset using tuples as the keys, and one of your operations is to
>> shorten all keys by removing their first elements. Current Python
>> r
On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
> On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
> wrote:
>> Your original use-case, where you want to change the type of tail from
>> a list to something else, is simply solved by one extra line of code:
>>
>> head, *tail = sequence
>>
On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
wrote:
> Your original use-case, where you want to change the type of tail from a
> list to something else, is simply solved by one extra line of code:
>
> head, *tail = sequence
> tail = tuple(tail)
That achieves the goal of having tail as a diff
On Dec 27, 5:10 pm, Steven D'Aprano wrote:
> On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> Your original use-case, where you want to change the type of tail from a
> list to something else, is simply solved by one extra line of code:
>
> head, *tail = sequence
> tail = tuple(tail)
i wonder i
On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> Explicit and implicit are not well-defined terms,
We can at least agree on that.
> but I would say that
> at the moment the signal is implicit, in the sense that one cannot see
> what is going on by considering the rhs in isolation.
That is a
On Mon, 26 Dec 2011 13:51:50 -0800, Eelco wrote:
[...]
>> If your point is that parens are used more often than
>> packing/unpacking, that's almost certainly true, since function calls
>> (including method invocations) are so prevalent in pretty much any
>> code. But what does that prove?
>
> That
On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:
> On Dec 25, 6:05 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
[...]
>> > How is 'head, *tail = sequence' or semantically entirely
>> > equivalently, 'head, tail::list = sequence'
On Dec 27, 1:52 am, Chris Angelico wrote:
> On Tue, Dec 27, 2011 at 10:44 AM, Eelco wrote:
> > extended collection unpacking, as in 'head,*tail=sequence', is quite a
> > rare construct indeed, and here I very strongly feel a more explicit
> > syntax is preferrable.
>
> You may be right, but...
>
On Tue, Dec 27, 2011 at 10:44 AM, Eelco wrote:
> extended collection unpacking, as in 'head,*tail=sequence', is quite a
> rare construct indeed, and here I very strongly feel a more explicit
> syntax is preferrable.
You may be right, but...
> ... if collection packing/unpacking would be
> presen
On Dec 26, 11:27 pm, Chris Angelico wrote:
> On Tue, Dec 27, 2011 at 8:51 AM, Eelco wrote:
> > That proves the original point of contention: that [Steve's demo code] is
> > suboptimal language design, not because terseness always trumps
> > verbosity, but because commonly-used constructs (such as
On Tue, Dec 27, 2011 at 9:12 AM, Eelco wrote:
> On Dec 26, 10:05 pm, Chris Angelico wrote:
>> A constraint can be applied at compile time or at run time. It'd be
>> valid to apply them at edit time, if you so chose - your editor could
>> refuse to save your file until you fix the problem. Doesn't
On Tue, Dec 27, 2011 at 8:51 AM, Eelco wrote:
> That proves the original point of contention: that [Steve's demo code] is
> suboptimal language design, not because terseness always trumps
> verbosity, but because commonly-used constructs (such as parenthesis
> or round brackets or whatever you wis
On Dec 26, 10:05 pm, Chris Angelico wrote:
> On Tue, Dec 27, 2011 at 7:58 AM, Eelco wrote:
> > What you are talking about goes by the name of a 'dynamic type CHECK';
> > some kind of syntactic sugar for something like
> > 'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
> > runti
On Dec 26, 10:01 pm, Chris Angelico wrote:
> On Tue, Dec 27, 2011 at 7:39 AM, Eelco wrote:
> > Now try it without changing the subject from round braces to
> > everything but round braces.
>
> Around here, the term "braces" means the curly ones - { and } - that
> delimit blocks of code in C, and
On Dec 25, 6:05 pm, Steven D'Aprano wrote:
> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
> > On Dec 25, 2:12 pm, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
> >> > On Dec 20, 4:30 am, alex23 wrote:
> >> >> On Dec 19, 8:15 p
On Tue, Dec 27, 2011 at 7:58 AM, Eelco wrote:
> What you are talking about goes by the name of a 'dynamic type CHECK';
> some kind of syntactic sugar for something like
> 'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
> runtime concept...
>
> By contrast, here is the first googl
On Tue, Dec 27, 2011 at 7:39 AM, Eelco wrote:
> Now try it without changing the subject from round braces to
> everything but round braces.
Around here, the term "braces" means the curly ones - { and } - that
delimit blocks of code in C, and dictionaries/sets in Python.
"Brackets" may be what you
On Dec 25, 5:23 pm, Chris Angelico wrote:
> On Mon, Dec 26, 2011 at 2:38 AM, Eelco wrote:
> > Until that time, im going
> > to ask you to take 'type constraint' by its literal meaning; a
> > coercion of the type of a symbol, rather than whatever particular
> > meaning it has acquired for you (it
On Dec 25, 5:15 pm, Steven D'Aprano wrote:
> On Sun, 25 Dec 2011 06:55:28 -0800, Eelco wrote:
> > Anyway, braces are used at
> > least an order of magnitude more than collection packing/ unpacking in
> > typical code.
>
> That's a wild and unjustified claim. Here's a quick and dirty test, using
>
On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
> On Dec 25, 2:12 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
>> > On Dec 20, 4:30 am, alex23 wrote:
>> >> On Dec 19, 8:15 pm, Eelco wrote:
>>
>> >> > What does that have to do w
On Mon, Dec 26, 2011 at 2:38 AM, Eelco wrote:
> Until that time, im going
> to ask you to take 'type constraint' by its literal meaning; a
> coercion of the type of a symbol, rather than whatever particular
> meaning it has acquired for you (it might help if you explained that).
> Im not sure if i
On Sun, 25 Dec 2011 06:55:28 -0800, Eelco wrote:
> Anyway, braces are used at
> least an order of magnitude more than collection packing/ unpacking in
> typical code.
That's a wild and unjustified claim. Here's a quick and dirty test, using
the standard library as an example of typical idiomati
On Dec 25, 2:13 pm, Steven D'Aprano wrote:
> On Sat, 24 Dec 2011 06:47:21 -0800, Eelco wrote:
> > I would like to be able to write something like:
>
> > a, middle::tuple, b = ::sequence
>
> > Where I would like the extra :: before the sequence to explicitly signal
> > collection unpacking on the r
On Dec 25, 1:50 pm, Steven D'Aprano wrote:
> On Sat, 24 Dec 2011 06:45:01 -0800, Eelco wrote:
> > Can you give an example of a construct in python where two whitespace
> > delimited identifiers are legal?
>
> Not apart from the trivial case of two identifiers separated by newlines.
>
> What's your
On Dec 25, 2:12 pm, Steven D'Aprano wrote:
> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
> > On Dec 20, 4:30 am, alex23 wrote:
> >> On Dec 19, 8:15 pm, Eelco wrote:
>
> >> > What does that have to do with collection packing/unpacking?
>
> >> It's mocking your insistance that collection unpa
On Dec 25, 2011 2:55 PM, "Eelco" wrote:
>
> On Dec 25, 2:01 am, Rick Johnson wrote:
> > On Dec 24, 6:24 pm, alex23 wrote:
> >
> > > That you're a condescending douchebag with nothing of value to
> > > contribute?
> >
> > > Crystal.
> >
> > Take it from me Eelco. Once Alex drops into your thread
On Dec 25, 1:45 pm, Steven D'Aprano wrote:
> On Sat, 24 Dec 2011 06:54:07 -0800, Eelco wrote:
> > Context dependence is not something to be avoided at all costs, but all
> > else being equal, less is certainly more. The general concept of
> > grouping thing together which parenthesis is an extreme
On Dec 25, 2:01 am, Rick Johnson wrote:
> On Dec 24, 6:24 pm, alex23 wrote:
>
> > That you're a condescending douchebag with nothing of value to
> > contribute?
>
> > Crystal.
>
> Take it from me Eelco. Once Alex drops into your thread and starts
> name calling, it's over my friend.
Yes, he has
On Sat, 24 Dec 2011 06:47:21 -0800, Eelco wrote:
> I would like to be able to write something like:
>
> a, middle::tuple, b = ::sequence
>
> Where I would like the extra :: before the sequence to explicitly signal
> collection unpacking on the rhs, to maintain the symmetry with
> collection unpa
On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
> On Dec 20, 4:30 am, alex23 wrote:
>> On Dec 19, 8:15 pm, Eelco wrote:
>>
>> > What does that have to do with collection packing/unpacking?
>>
>> It's mocking your insistance that collection unpacking is a type
>> constraint.
>
> This is really
On Sat, 24 Dec 2011 06:45:01 -0800, Eelco wrote:
> Can you give an example of a construct in python where two whitespace
> delimited identifiers are legal?
Not apart from the trivial case of two identifiers separated by newlines.
What's your point?
--
Steven
--
http://mail.python.org/mailman
On Sat, 24 Dec 2011 06:54:07 -0800, Eelco wrote:
> Context dependence is not something to be avoided at all costs, but all
> else being equal, less is certainly more. The general concept of
> grouping thing together which parenthesis is an extremely pervasive one
> in programming, and thus deserve
On Dec 24, 6:24 pm, alex23 wrote:
> That you're a condescending douchebag with nothing of value to
> contribute?
>
> Crystal.
Take it from me Eelco. Once Alex drops into your thread and starts
name calling, it's over my friend.
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 25, 12:39 am, Eelco wrote:
> This is really going to be the last time I waste any words on this
Oh hey, don't feel you actually have to justify the bullshit you're
talking for my sake.
> In case of python, collection PACKING (not unpacking) is signaled by a
> construct that can be viewed
On Sun, Dec 25, 2011 at 4:23 AM, Eelco wrote:
> Thats not a fair point, but more nitpicking. Yes, I should have been
> more precise: in python, 'whitespace' is not a single beast like in
> most languages, but newlines have a special meaning. I was obviously
> not talking about those. Want to try a
On Dec 24, 4:01 pm, Chris Angelico wrote:
> On Sun, Dec 25, 2011 at 1:45 AM, Eelco wrote:
> > Can you give an example of a construct in python where two whitespace
> > delimited identifiers are legal?
>
> What do you mean? Two identifiers, separated only by whitespace and no
> keyword or operator
On Dec 24, 3:57 pm, Chris Angelico wrote:
> On Sun, Dec 25, 2011 at 1:47 AM, Eelco wrote:
> > a, middle::tuple, b = ::sequence
>
> Then it ought to be
>
> ::(a, middle::tuple, b) = ::sequence
>
> or something, because you're doing the same thing on both sides.
>
> ChrisA
Thats a fair point; some
On Sun, Dec 25, 2011 at 1:45 AM, Eelco wrote:
> Can you give an example of a construct in python where two whitespace
> delimited identifiers are legal?
What do you mean? Two identifiers, separated only by whitespace and no
keyword or operator?
def foo():
asdf
qwer
Perfectly legal, two
On Sun, Dec 25, 2011 at 1:47 AM, Eelco wrote:
> a, middle::tuple, b = ::sequence
Then it ought to be
::(a, middle::tuple, b) = ::sequence
or something, because you're doing the same thing on both sides.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 22, 2:12 pm, Steven D'Aprano wrote:
> On Thu, 22 Dec 2011 06:49:16 -0500, Neal Becker wrote:
> > I agree with the OP that the current syntax is confusing. The issue is,
> > the meaning of * is context-dependent.
>
> Here you are complaining about an operator being "confusing" because it
>
On Dec 20, 6:47 am, Steven D'Aprano wrote:
> On Mon, 19 Dec 2011 19:35:20 -0800, alex23 wrote:
> > Eelco wrote:
> >> Having two seperate symbols seperated by whitespace, as in @list args
> >> strikes me as a terrible break of normal python lexical rules.
>
> > You mean like 'is not'? And the upco
On Dec 20, 4:35 am, alex23 wrote:
> Eelco wrote:
> > Having two seperate symbols seperated by whitespace, as in @list args
> > strikes me as a terrible break of normal python lexical rules.
>
> You mean like 'is not'? And the upcoming 'yield from'?
Im not sure why, but this feels like something
On Dec 21, 4:48 pm, Neal Becker wrote:
> Clarification: where can packing/unpacking syntax be used?
>
> It would be great if it were valid essentially anywhere (not limited to
> parameter passing).
>
> What about constructs like:
>
> a, @tuple tail, b = sequence?
This has come up many times in th
On Dec 20, 4:30 am, alex23 wrote:
> On Dec 19, 8:15 pm, Eelco wrote:
>
> > What does that have to do with collection packing/unpacking?
>
> It's mocking your insistance that collection unpacking is a type
> constraint.
This is really going to be the last time I waste any words on this:
The sent
Chris Angelico wrote:
> On Fri, Dec 23, 2011 at 1:13 AM, Hans Mulder wrote:
>> How about:
>>
>>
>> ...
>>
>>
>> More more readable! And it's a standard!
>
> Unfortunately it's not Pythonic, because indentation is insignificant.
Easy-peasy:
Mel.
> We need to ado
On Fri, Dec 23, 2011 at 1:13 AM, Hans Mulder wrote:
> How about:
>
>
> ...
>
>
> More more readable! And it's a standard!
Unfortunately it's not Pythonic, because indentation is insignificant.
We need to adopt a more appropriate form. Eliminate all the
tags and use indentation to mark the end
On 22/12/11 14:12:57, Steven D'Aprano wrote:
On Thu, 22 Dec 2011 06:49:16 -0500, Neal Becker wrote:
I agree with the OP that the current syntax is confusing. The issue is,
the meaning of * is context-dependent.
Here you are complaining about an operator being "confusing" because it
is contex
On Fri, Dec 23, 2011 at 12:12 AM, Steven D'Aprano
wrote:
> class MyClass superclasslist A, B C:
> def method argumentlist self, x, y:
> t = tuple 1, 2 tuple 3, 4 endtuple endtuple
> return group x + y endgroup * group x - y endgroup
>
>
> Much less confusing!
A definite improveme
On Thu, 22 Dec 2011 06:49:16 -0500, Neal Becker wrote:
> I agree with the OP that the current syntax is confusing. The issue is,
> the meaning of * is context-dependent.
Here you are complaining about an operator being "confusing" because it
is context-dependent, in a post where you strip all c
I agree with the OP that the current syntax is confusing. The issue is, the
meaning of * is context-dependent.
Why not this:
Func (*args) == Func (unpack (args))
def Func (*args) == Func (pack (args))
That seems very clear IMO
--
http://mail.python.org/mailman/listinfo/python-list
On 21 December 2011 15:48, Neal Becker wrote:
> Clarification: where can packing/unpacking syntax be used?
>
> It would be great if it were valid essentially anywhere (not limited to
> parameter passing).
>
> What about constructs like:
>
> a, @tuple tail, b = sequence?
>>> a, *b, c = range(10)
Neal Becker wrote:
Clarification: where can packing/unpacking syntax be used?
It would be great if it were valid essentially anywhere (not limited to
parameter passing).
What about constructs like:
a, @tuple tail, b = sequence?
You mean like Python 3's:
a, *middle, b = sequence
?
--
htt
Clarification: where can packing/unpacking syntax be used?
It would be great if it were valid essentially anywhere (not limited to
parameter passing).
What about constructs like:
a, @tuple tail, b = sequence?
--
http://mail.python.org/mailman/listinfo/python-list
On 20 December 2011 20:51, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> Languages shouldn't depend on advanced editor
> features or special keyboards -- that way leads to ColorForth and APL.
>
True, but dependency on a tool is not the same as being crafted to work
best on the
On Mon, 19 Dec 2011 19:38:52 -0800, alex23 wrote:
> On Dec 20, 7:57 am, Andrew Berg wrote:
>> But what about the example he gave about being logged into a customer's
>> machine with only ed available? I suppose such fools would not be
>> worthy of your business.
>
> Do you mean directly editing
20.12.11 07:47, Steven D'Aprano написав(ла):
Space-delimited tokens are hardly rare in Python, e.g.:
import module as name
for x in sequence
if flag
elif condition
while condition
with obj
del name
return to_be or not to_be if this is question else None
--
http://mail.python.org/mailman/listi
Steven D'Aprano wrote:
> Nevertheless, I think the suggested syntax "@list args" is awful.
Yep, and it's the least awful part of the entire proposal.
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 19 Dec 2011 19:35:20 -0800, alex23 wrote:
> Eelco wrote:
>> Having two seperate symbols seperated by whitespace, as in @list args
>> strikes me as a terrible break of normal python lexical rules.
>
> You mean like 'is not'? And the upcoming 'yield from'?
Also "not in".
Space-delimited
On Tue, Dec 20, 2011 at 2:31 PM, alex23 wrote:
> On Dec 19, 2:35 pm, Chris Angelico wrote:
>> Point to note:
>>
>> list,set = set,list # Request a death sentence from the next maintainer
>>
>> is perfectly legal code. Now, what does your "args=" line do?
>>
>> ChrisA
>
> Why are you directing th
On 12/19/2011 9:38 PM, alex23 wrote:
> Do you mean directly editing the source code on a production machine?
> Because that's pretty much the only scenario I can come up with where
> that's plausible.
You'd have to ask Steven D'Aprano; it was his scenario.
--
CPython 3.2.2 | Windows NT 6.1.7601.1
On Dec 19, 2:35 pm, Chris Angelico wrote:
> Point to note:
>
> list,set = set,list # Request a death sentence from the next maintainer
>
> is perfectly legal code. Now, what does your "args=" line do?
>
> ChrisA
Why are you directing this at my mocking of the OPs idea when the same
issue is pres
On Dec 20, 7:57 am, Andrew Berg wrote:
> But what about the example he gave about being logged into a customer's
> machine with only ed available? I suppose such fools would not be worthy
> of your business.
Do you mean directly editing the source code on a production machine?
Because that's pret
Eelco wrote:
> Having two seperate symbols seperated by whitespace, as in @list args
> strikes me as a terrible break of normal python lexical rules.
You mean like 'is not'? And the upcoming 'yield from'?
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 19, 8:15 pm, Eelco wrote:
> What does that have to do with collection packing/unpacking?
It's mocking your insistance that collection unpacking is a type
constraint.
--
http://mail.python.org/mailman/listinfo/python-list
On 12/19/2011 7:18 PM, Roy Smith wrote:
> Sorry, I wasn't meaning to imply support for the syntax proposal. Just
> reacting to the (seemingly unrelated) comment that a customer with
> foolish access policies would not be worthy of your business.
It was directed at Rick, and by "your", I was refer
On 20 December 2011 01:18, Roy Smith wrote:
> Sorry, I wasn't meaning to imply support for the syntax proposal. Just
> reacting to the (seemingly unrelated) comment that a customer with foolish
> access policies would not be worthy of your business. Only because I've
> been in the situation of
Sorry, I wasn't meaning to imply support for the syntax proposal. Just
reacting to the (seemingly unrelated) comment that a customer with foolish
access policies would not be worthy of your business. Only because I've been
in the situation of having to provide remote support to major customers
On 20 December 2011 00:30, Roy Smith wrote:
> In article ,
> Andrew Berg wrote:
>
> > But what about the example he gave about being logged into a customer's
> > machine with only ed available? I suppose such fools would not be worthy
> > of your business.
>
> The customer is always right. Esp
In article ,
Andrew Berg wrote:
> But what about the example he gave about being logged into a customer's
> machine with only ed available? I suppose such fools would not be worthy
> of your business.
The customer is always right. Especially when the support contract is
big enough to make or
On 12/18/2011 8:16 PM, Rick Johnson wrote:
> On Dec 18, 7:26 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> Not everybody uses editors more advanced than Notepad.
> And they have no excuse for NOT using a better one. Well, except for a
> "foolish consistency" that is!
But what abou
Evan Driscoll wrote:
>> I'm not an expert on Google's syntax, but if you search for "python,
>> optionally with function", isn't that the same as just searching for
>> "python" since it will return hits either with or without "function"?
> Chris Angelico's interpretation is correct: I did four
On Dec 19, 1:59 am, Rick Johnson wrote:
> On Dec 17, 11:33 pm, Evan Driscoll wrote:
>
> > On 12/17/2011 22:52, buck wrote:> Try these on for size.
>
> > > head, @tuple tail = sequence
> > > def foo(@list args, @dict kwargs): pass
> > > foo(@args, @kwargs)
>
> > > For backward compa
On Dec 19, 3:23 am, alex23 wrote:
> Evan Driscoll wrote:
> > My problem with it is that it in some sense is forcing me to make a
> > decision I don't care about. Yes, what we have now is less flexible, but
> > I have *never* said "man, I wish this *args parameter were a list
> > instead of a tupl
On Mon, Dec 19, 2011 at 1:23 PM, alex23 wrote:
> Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type
> constraint. I propose that:
>
> args = @set list(args)
>
> Will coerce args into a list and then give me a set in return.
Point to note:
list,set = set,list # Request a death
On Sun, 18 Dec 2011 20:00:59 -0700, Ian Kelly wrote:
> On Sun, Dec 18, 2011 at 6:26 PM, Steven D'Aprano
> wrote:
>> On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:
>>
>> [...]
>>> so unless you're opposed to using an editor more advanced than
>>> Notepad, you'll type in "varargs", it'll
On Sun, Dec 18, 2011 at 6:26 PM, Steven D'Aprano
wrote:
> On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:
>
> [...]
>> so unless you're opposed to using an editor more
>> advanced than Notepad, you'll type in "varargs", it'll turn purple or
>> whatever, and you'll go "oh that's a keyword.
On 17Dec2011 22:43, Evan Driscoll wrote:
| On 12/17/2011 21:42, Chris Angelico wrote:
| > Welcome to the list! If you're curious as to what's happened, check
| > the archives:
| > http://mail.python.org/pipermail/python-list/
| Thanks! Incidentally, is there a good way to respond to the original
|
Evan Driscoll wrote:
> My problem with it is that it in some sense is forcing me to make a
> decision I don't care about. Yes, what we have now is less flexible, but
> I have *never* said "man, I wish this *args parameter were a list
> instead of a tuple".
And if you _did_, then one of the first
On Dec 18, 7:26 pm, Steven D'Aprano wrote:
> Not everybody uses editors more advanced than Notepad.
And they have no excuse for NOT using a better one. Well, except for a
"foolish consistency" that is!
> Even those who do
> may not have an editor that understands Python keywords, or has an
> obso
On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:
[...]
> so unless you're opposed to using an editor more
> advanced than Notepad, you'll type in "varargs", it'll turn purple or
> whatever, and you'll go "oh that's a keyword."
Not everybody uses editors more advanced than Notepad. Even th
On Dec 18, 8:35 am, Eelco wrote:
> On Dec 18, 6:33 am, Evan Driscoll wrote:
> Good point; technically the askeriskes could be kept for backwards
> compatibility, but that would break 'there should only be one way to
> do it'.
I believe it's high time for the upper society of this community to
r
On Dec 17, 11:33 pm, Evan Driscoll wrote:
> On 12/17/2011 22:52, buck wrote:> Try these on for size.
>
> > head, @tuple tail = sequence
> > def foo(@list args, @dict kwargs): pass
> > foo(@args, @kwargs)
>
> > For backward compatibility, we could say that the unary * is identical to
On Dec 17, 10:52 pm, buck wrote:
> [...]
> As for the separator, let's examine the available ascii punctuation.
> Excluding valid variable characters, whitespace, and operators, we have:
>
> ! -- ok.
No, there are better uses for that char.
> " -- can't use this. Would look like a string.
> # --
On 12/18/2011 8:35, Eelco wrote:
> No, its not type *checking*, its type *declaration*. I tried to go to
> great lengths to point that out, but it appears I did not do a very
> good job :). Type declaration is exactly what I want, and insofar this
> syntax has already found adoptation elsewhere, il
On 12/18/2011 1:31, Steven D'Aprano wrote:
> And rebutted. Modesty[1] prevents me from quoting myself, but here are
> some links to searches:
>
> http://duckduckgo.com/?q=python+asterisk
> http://duckduckgo.com/?q=python+*
OK, so if you search using the right search engine, you *might* get a
link
On 12/18/2011 2:36, Steven D'Aprano wrote:
> The barrier to new keywords in Python is very high. Not going to
> happen for something that already has perfectly good syntax already
> familiar to Python and Ruby programmers. Might else well try to get C
> and Java to stop using "..." (ellipses).
I ag
1 - 100 of 132 matches
Mail list logo
