On Jan 3, 3:38 am, alex23 wuwe...@gmail.com wrote:
On Dec 27 2011, 8:01 pm, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 27 2011, 8:01 pm, Eelco hoogendoorn.ee...@gmail.com 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
On Jan 2, 8:38 pm, alex23 wuwe...@gmail.com 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.
--
On Jan 3, 3:39 pm, Rick Johnson rantingrickjohn...@gmail.com 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 Dec 28, 11:29 pm, Lie Ryan lie.1...@gmail.com 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
On Dec 29, 2:23 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
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 = sequence
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 Fri, Dec 30, 2011 at 10:24 AM, Lie Ryan lie.1...@gmail.com 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
On Dec 27, 11:57 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:
On Dec 25, 6:05 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
[...]
How is 'head,
On Dec 28, 2:11 am, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Dec 27, 5:10 pm, Steven D'Aprano steve
+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
On Dec 28, 8:08 am, Chris Angelico ros...@gmail.com wrote:
On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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,
On Dec 28, 12:07 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
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 27, 1:52 am, Chris Angelico ros...@gmail.com wrote:
On Tue, Dec 27, 2011 at 10:44 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Mon, 26 Dec 2011 13:41:34 -0800, Eelco wrote:
On Dec 25, 6:05 pm, Steven D'Aprano steve
+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' any
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 proves
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 Dec 27, 5:10 pm, Steven D'Aprano steve
+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 one extra line of code:
head, *tail = sequence
On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:
On Wed, Dec 28, 2011 at 10:10 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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:
On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Dec 25, 5:15 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
On Dec 25, 5:23 pm, Chris Angelico ros...@gmail.com wrote:
On Mon, Dec 26, 2011 at 2:38 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Tue, Dec 27, 2011 at 7:39 AM, Eelco hoogendoorn.ee...@gmail.com 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.
On Tue, Dec 27, 2011 at 7:58 AM, Eelco hoogendoorn.ee...@gmail.com 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,
On Dec 25, 6:05 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
On Dec 25, 2:12 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
On Dec 20, 4:30 am, alex23
On Dec 26, 10:01 pm, Chris Angelico ros...@gmail.com wrote:
On Tue, Dec 27, 2011 at 7:39 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 26, 10:05 pm, Chris Angelico ros...@gmail.com wrote:
On Tue, Dec 27, 2011 at 7:58 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Tue, Dec 27, 2011 at 8:51 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Tue, Dec 27, 2011 at 9:12 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 26, 10:05 pm, Chris Angelico ros...@gmail.com 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
On Dec 26, 11:27 pm, Chris Angelico ros...@gmail.com wrote:
On Tue, Dec 27, 2011 at 8:51 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
That proves the original point of contention: that [Steve's demo code] is
suboptimal language design, not because terseness always trumps
verbosity, but
On Tue, Dec 27, 2011 at 10:44 AM, Eelco hoogendoorn.ee...@gmail.com 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
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 deserves
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
--
On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
On Dec 20, 4:30 am, alex23 wuwe...@gmail.com wrote:
On Dec 19, 8:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
What does that have to do with collection packing/unpacking?
It's mocking your insistance that collection unpacking is a type
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 unpacking
On Dec 25, 2:01 am, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Dec 24, 6:24 pm, alex23 wuwe...@gmail.com 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,
On Dec 25, 1:45 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
On Dec 25, 2011 2:55 PM, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 25, 2:01 am, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Dec 24, 6:24 pm, alex23 wuwe...@gmail.com wrote:
That you're a condescending douchebag with nothing of value to
contribute?
Crystal.
Take
On Dec 25, 2:12 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
On Dec 20, 4:30 am, alex23 wuwe...@gmail.com wrote:
On Dec 19, 8:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
What does that have to do with collection
On Dec 25, 1:50 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
On Dec 25, 2:13 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
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 idiomatic
On Mon, Dec 26, 2011 at 2:38 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
On Dec 25, 2:12 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
On Dec 20, 4:30 am, alex23 wuwe...@gmail.com wrote:
On Dec 19, 8:15 pm, Eelco hoogendoorn.ee...@gmail.com
On Dec 20, 4:30 am, alex23 wuwe...@gmail.com wrote:
On Dec 19, 8:15 pm, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 21, 4:48 pm, Neal Becker ndbeck...@gmail.com 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
On Dec 20, 4:35 am, alex23 wuwe...@gmail.com wrote:
Eelco hoogendoorn.ee...@gmail.com 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
On Dec 20, 6:47 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 19 Dec 2011 19:35:20 -0800, alex23 wrote:
Eelco hoogendoorn.ee...@gmail.com wrote:
Having two seperate symbols seperated by whitespace, as in @list args
strikes me as a terrible break of normal python
On Dec 22, 2:12 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
On Sun, Dec 25, 2011 at 1:47 AM, Eelco hoogendoorn.ee...@gmail.com 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 Sun, Dec 25, 2011 at 1:45 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 24, 3:57 pm, Chris Angelico ros...@gmail.com wrote:
On Sun, Dec 25, 2011 at 1:47 AM, Eelco hoogendoorn.ee...@gmail.com 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.
On Dec 24, 4:01 pm, Chris Angelico ros...@gmail.com wrote:
On Sun, Dec 25, 2011 at 1:45 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Sun, Dec 25, 2011 at 4:23 AM, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 25, 12:39 am, Eelco hoogendoorn.ee...@gmail.com 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
On Dec 24, 6:24 pm, alex23 wuwe...@gmail.com 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.
--
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 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
On Fri, Dec 23, 2011 at 12:12 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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
On Fri, Dec 23, 2011 at 1:13 AM, Hans Mulder han...@xs4all.nl wrote:
How about:
class name=MyClass superclasses=A, B, C
...
/class
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.
Chris Angelico wrote:
On Fri, Dec 23, 2011 at 1:13 AM, Hans Mulder han...@xs4all.nl wrote:
How about:
class name=MyClass superclasses=A, B, C
...
/class
More more readable! And it's a standard!
Unfortunately it's not Pythonic, because indentation is insignificant.
Easy-peasy:
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
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
?
--
On 21 December 2011 15:48, Neal Becker ndbeck...@gmail.com 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 =
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
--
On Mon, 19 Dec 2011 19:38:52 -0800, alex23 wrote:
On Dec 20, 7:57 am, Andrew Berg bahamutzero8...@gmail.com 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
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 tool
On Dec 19, 3:23 am, alex23 wuwe...@gmail.com wrote:
Evan Driscoll edrisc...@wisc.edu 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
On Dec 19, 1:59 am, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Dec 17, 11:33 pm, Evan Driscoll edrisc...@wisc.edu 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,
Evan Driscoll edrisc...@wisc.edu 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
On 12/18/2011 8:16 PM, Rick Johnson wrote:
On Dec 18, 7:26 pm, Steven D'Aprano steve
+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 about
In article mailman.3827.1324331890.27778.python-l...@python.org,
Andrew Berg bahamutzero8...@gmail.com 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
On 20 December 2011 00:30, Roy Smith r...@panix.com wrote:
In article mailman.3827.1324331890.27778.python-l...@python.org,
Andrew Berg bahamutzero8...@gmail.com wrote:
But what about the example he gave about being logged into a customer's
machine with only ed available? I suppose such
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
On 20 December 2011 01:18, Roy Smith r...@panix.com 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
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 referring
On Dec 19, 8:15 pm, Eelco hoogendoorn.ee...@gmail.com 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
Eelco hoogendoorn.ee...@gmail.com 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 20, 7:57 am, Andrew Berg bahamutzero8...@gmail.com 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
On Dec 19, 2:35 pm, Chris Angelico ros...@gmail.com 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
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
On Tue, Dec 20, 2011 at 2:31 PM, alex23 wuwe...@gmail.com wrote:
On Dec 19, 2:35 pm, Chris Angelico ros...@gmail.com 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
On Mon, 19 Dec 2011 19:35:20 -0800, alex23 wrote:
Eelco hoogendoorn.ee...@gmail.com 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 Sat, 17 Dec 2011 23:33:27 -0600, Evan Driscoll wrote:
This would suggest perhaps some keywords might be called for instead of
operators.
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
On Sun, Dec 18, 2011 at 6:31 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
My normal first place to look for something is Wikipedia. Enjoy it before
SOPA kills it.
http://en.wikipedia.org/wiki/Asterisk#Programming_languages
I would never expect to find this sort of thing in
On Sat, 17 Dec 2011 21:03:01 -0600, Evan Driscoll wrote:
Something like ML or Haskell, which does not even allow integer to
double promotions, is very strong typing. Something like Java, which
allows some arithmetic conversion and also automatic stringification (a
la 1 + 1) is somewhere in
In article mailman.3787.1324197792.27778.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Never underestimate the power of Python's introspection tools, especially
the two simplest ones: print and type. Often you will learn more in 10
minutes experimentation than in an hour
On Mon, Dec 19, 2011 at 12:58 AM, Roy Smith r...@panix.com wrote:
In addition to print and type, I'm a big fan of dir(). Often, I know an
object has a method to do what I want, but I can't remember the name.
For example, the other day, I was using a set (which I don't use very
often). I
On Dec 18, 1:59 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 17 Dec 2011 06:38:22 -0800, Eelco wrote:
Type constraints:
In case the asterisk is not used to signal unpacking, but rather to
signal packing, its semantics is essentially that of a type constraint.
On Dec 18, 5:52 am, buck workithar...@gmail.com wrote:
I like the spirit of this. Let's look at your examples.
Glad to see an actual on-topic reply; thanks.
Examples of use:
head, tail::tuple = ::sequence
def foo(args::list, kwargs::dict): pass
foo(::args, ::kwargs)
My
On Dec 18, 6:33 am, Evan Driscoll edrisc...@wisc.edu 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
I'm just going to throw myself in the conversation obtusely.I felt we
needed some real code. These are literally the first two samples I had on
hand.
!!! OUT OF CONTEXT REAL CODE ALERT !!!
###
formatter = formatter.format(**color).replace((,{).replace(),})
On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote:
Casts or conversions are a runtime concept; im talking about
declarations. That seems to be the source of your confusion.
Everything in Python happens at runtime, apart from compilation of source
code into byte code. Python doesn't have
On 18 dec, 18:03, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote:
Casts or conversions are a runtime concept; im talking about
declarations. That seems to be the source of your confusion.
Everything in Python happens at runtime,
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 agree
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 to
1 - 100 of 132 matches
Mail list logo
