thank you both for your replies. Unfortunately it is a pre-existing
file format imposed by an external system that I can't
change. Thank you for the code snippet.
Hi Richard,
Despite the fact that it is a preexisting format, it is very close
indeed to valid YAML code.
Writing your own
There is linalg.pinv, which computes a pseudoinverse based on SVD that
works on all matrices, regardless of the rank of the matrix. It merely
approximates A*A.I = I as well as A permits though, rather than being
a true inverse, which may not exist.
Anyway, there are no general answers for this
On Apr 10, 3:36 am, Kiuhnm kiuhnm03.4t.yahoo.it wrote:
On 4/10/2012 14:29, Ulrich Eckhardt wrote:
Am 09.04.2012 20:57, schrieb Kiuhnm:
Do you have some real or realistic (but easy and self-contained)
examples when you had to define a (multi-statement) function and pass it
to another
On Feb 12, 7:41 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
This is only peripherally a Python problem, but in case anyone has any
good ideas I'm going to ask it.
I have a routine to calculate an approximation of Lambert's W function,
and then apply a root-finding
On Jan 27, 12:04 am, Wanderer wande...@dialup4less.com wrote:
On Jan 26, 2:56 pm, Wanderer wande...@dialup4less.com wrote:
On Jan 25, 1:12 pm, Wanderer wande...@dialup4less.com wrote:
I found it it is in the stsci package.
On Jan 24, 11:36 am, Eelco hoogendoorn.ee...@gmail.com wrote
On Jan 23, 6:54 pm, Wanderer wande...@dialup4less.com wrote:
Back in scipy 0.7 there was a package called stsci that had function
scipy.stsci.image.median that created a median image from a stack of
images. The stsci package is dropped in v0.8. Has this functionality
been moved to a different
The grep solution is not cross-platform, and not really an answer to a
question about python.
The by-line iteration examples are inefficient and bad practice from a
numpy/vectorization perspective.
I would advice to do it the numpythonic way (untested code):
breakpoints = [3, 5, 7]
data =
On 13 jan, 20:04, Ethan Furman et...@stoneleaf.us wrote:
With NaN, it is possible to get a list that will not properly sort:
-- NaN = float('nan')
-- spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
-- sorted(spam)
[1, 2, nan, 3, nan, 4, 5, 7, nan]
I'm constructing a Null object with the semantics
i havnt read every post in great detail, but it doesnt seem like your
actual question has been answered, so ill give it a try.
AFAIK, changing __dict__ to be an ordereddict is fundamentally
impossible in python 2. __dict__ is a builtin language construct
hardcoded into the C API. There is no way
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
Why do people use pretty when we already have words that carry more
specific meaning? Because they are lazy! And laziness begets
stupidity.
No, that would be because they are not autistic. Most people like
having a repertoire of words with subtly different meanings in their
natural language,
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
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 Dec 28, 2:56 am, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Dec 27, 3:44 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
Despite the fact that you mis-attributed that quote to me, im going to
be a little bit offended in the name of its actual author anyway.
Thats a lot of words
On Dec 27, 6:59 am, Carl Smith carl.in...@gmail.com wrote:
On Dec 20, 10:58 am, Andrea Crotti andrea.crott...@gmail.com wrote:
On 12/20/2011 03:51 AM, Raymond Hettinger wrote:
Do you use IDLE when teaching Python?
If not, what is the tool of choice?
Students may not be
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
On Dec 27, 6:53 pm, Lie Ryan lie.1...@gmail.com wrote:
On 12/27/2011 10:41 PM, Eelco wrote:
*Your suggestion of VIM is especially objectionable. Though I am sure
it is a great tool to you, the subject here is beginner education.
Just because it is a good tool for you, does not make
On Dec 27, 9:04 pm, Rick Johnson rantingrickjohn...@gmail.com wrote:
On Dec 27, 1:45 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 27, 6:53 pm, Lie Ryan lie.1...@gmail.com wrote:
On 12/27/2011 10:41 PM, Eelco wrote:
Before using VIM, I used to use gedit
Eelco, please don't get
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
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 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
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
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
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, 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 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
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 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
My first suggestion would be to keep the rendering in Python, if at
all feasible, and do only the actual simulation/computation in C.
Rasterizing a heightfield and rigid body plus some plash effects is
nothing that couldnt be done in PyOpenGL, or even something higher-
level like visvis or mayavi.
I taught a Python class just recently, and thought long and hard about
this problem. I settled on PyCharm and was happy with that.
My reasons:
- available on all main platoforms
- not entirely broken code completion (ive tried literally every
python editor, and pycharm is the only one that
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
, @kwargs)
For backward compatibility, we could say that the unary * is identical to
@list and unary ** is identical to @dict.
I like this idea much more than the original one.
+1. I will second that! Eelco has the CORRECT idea, but the WRONG
syntax!
Thanks, your opinion is noted
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
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
This is a follow-up discussion on my earlier PEP-suggestion. Ive
integrated the insights collected during the previous discussion, and
tried to regroup my arguments for a second round of feedback. Thanks
to everybody who gave useful feedback the last time.
PEP Proposal: Pythonification of the
On Dec 17, 6:18 pm, Chris Angelico ros...@gmail.com wrote:
On Sun, Dec 18, 2011 at 4:14 AM, Roy Smith r...@panix.com wrote:
Import wildcarding?
That's not an operator, any more than it is when used in filename
globbing. The asterisk _character_ has many meanings beyond those of
the
On Dec 16, 3:58 am, MRAB pyt...@mrabarnett.plus.com wrote:
On 16/12/2011 02:14, alex23 wrote:
Eelcohoogendoorn.ee...@gmail.com wrote:
To tie it back in with python language design; all the more reason
not to opt for pseudo-backwards compatibility. If python wants a
remainder function,
On Dec 16, 6:30 am, alex23 wuwe...@gmail.com wrote:
On Dec 16, 3:01 pm, Chris Angelico ros...@gmail.com wrote:
And I would be most sorry to see % renamed to mod in Python.
Hello, %s! My favourite number is %d. mod (Fred,42) # This just
looks wrong.
Finally we can give this operator a
On 16 dec, 18:38, rusi rustompm...@gmail.com wrote:
On Dec 16, 3:25 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
Pseudo-backwards compatibility with other
languages, I couldnt not care less for.
Double negations n Goedelian situations have interesting implications
(tho here its triple
On Dec 17, 12:49 am, Gregory Ewing greg.ew...@canterbury.ac.nz
wrote:
Eelco wrote:
the actual english usage of the phrase, which omits
the negation completely :). (I could care less)
No, that's the American usage. The English usage is
I couldn't care less, which has the advantage
On Dec 15, 4:43 am, rusi rustompm...@gmail.com wrote:
On Dec 14, 10:15 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
'Kindof' off-topic, but what the hell :).
deja-vu
We keep having these debates -- so I wonder how off-topic it is...
And so do famous
CSists:http://research.microsoft.com
On Dec 15, 11:47 am, Robert Kern robert.k...@gmail.com wrote:
On 12/14/11 12:32 PM, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 10:56:02 +0200, Jussi Piitulainen wrote:
I'm not misunderstanding any argument. There was no argument. There was
a blanket pronouncement that _in mathematics_ mod
On Dec 15, 11:56 am, rusi rustompm...@gmail.com wrote:
On Dec 15, 2:44 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
In other words, what logic needs is a better exception-handling
system, which completes the circle with programming languages quite
nicely. :)
Cute... but dangerously
On Dec 14, 4:18 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
They might not be willing to define it, but as soon as we programmers
do, well, we did.
Having studied the contemporary philosophy of mathematics, their concern
is probably that in their minds, mathematics is
On 14 dec, 09:56, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote:
Steven D'Aprano writes:
On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
[quoting Jussi Piitulainen jpiit...@ling.helsinki.fi]
They recognize modular arithmetic but for some reason insist that
there is no such _binary
On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com wrote:
On Dec 14, 4:18 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
They might not be willing to define it, but as soon as we programmers
do, well
On 14 dec, 13:22, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote:
Is someone saying that _division_ is not defined because -42 div
-5 is somehow both 9 and 8? Hm, yes, I see that someone might. The
two operations, div and rem, need to be defined together.
(There is no way to make
On Dec 14, 1:38 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Wed, 14 Dec 2011 02:09:32 -0800, Eelco wrote:
Arguably, the most elegant thing to do is to define integer division and
remainder as a single operation; which is not only the logical thing to
do
'Kindof' off-topic, but what the hell :).
On Dec 14, 5:13 pm, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 12:33, Eelco hoogendoorn.ee...@gmail.com wrote:
On 14 dec, 12:55, Arnaud Delobelle arno...@gmail.com wrote:
On 14 December 2011 07:49, Eelco hoogendoorn.ee...@gmail.com
On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote:
On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote:
But to relate it to the topic of this thread: no, the syntax does not
allow one to select the type of the resulting sequence. It always
constructs a list.
So by this argument
On Dec 13, 1:34 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 11:51 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
Either way, its not hard to add some detail to the semantics to allow
all this. Even this function definition:
def func(Foo(args), Foo(kwargs))
...could
On Dec 13, 2:41 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 4:40 PM, Eelco hoogendoorn.ee...@gmail.com wrote:
For a linked list, no *target and no copying is needed:
head, tail = llist
I have no idea what this means.
Each node of a linked list consists of a data
On Dec 13, 3:43 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
No more, or less, explicit than the difference between == and is.
== may be taken to mean identity comparison; 'equals' can only mean one
thing.
Nonsense
Python users generally follow the rule explicit is better than
implicit. Setting a general constraint and letting the language do
the right thing is a kind of black magic that feels off because it
tends to break that rule. But that's not to say that black magic
never wins -- just look
To answer that question: for the same reasons. The conversion is
wasteful; allowing python to do the right thing based on a
typeconstraint is not. Plus, it is less code, and more readable code;
the only rule you have to learn is quite general, which is that :: is
a type constraint annotation;
On 13 dec, 11:15, Arnaud Delobelle arno...@gmail.com wrote:
On 13 December 2011 09:50, Eelco hoogendoorn.ee...@gmail.com wrote:
To answer that question: for the same reasons. The conversion is
wasteful; allowing python to do the right thing based on a
typeconstraint is not. Plus
With all this being said, I must say that the notion of indtroducing
type constraints into Python is quite a radical one*, and one that
should not be taken lightly, so I understand the general conservative
vibe the notion is getting. It probably has implications beyond just
collection types, and
On 13 dec, 12:28, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 13 Dec 2011 02:46:13 -0800, Eelco wrote:
With all this being said, I must say that the notion of indtroducing
type constraints into Python is quite a radical one*,
Not that radical. Here's the creator
On 13 dec, 12:13, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
On Dec 13, 3:43 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
No more, or less, explicit
On 13 dec, 14:14, Chris Angelico ros...@gmail.com wrote:
On Tue, Dec 13, 2011 at 11:47 PM, Eelco hoogendoorn.ee...@gmail.com wrote:
def f(*args) *constructs* a tuple, it
doesn't perform a type-check.
I am talking about type constraints... A type-check is something
along the lines of type
On Dec 13, 8:11 pm, Cameron Simpson c...@zip.com.au wrote:
On 13Dec2011 00:30, Eelco hoogendoorn.ee...@gmail.com wrote:
| On Dec 13, 1:27 am, alex23 wuwe...@gmail.com wrote:
| On Dec 13, 3:12 am, Eelco hoogendoorn.ee...@gmail.com wrote:
| But to relate it to the topic of this thread
On Dec 13, 7:15 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Tue, Dec 13, 2011 at 1:44 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
'for i in llist' is not quite going to fly is it? Thats probably the
reason noone ever uses that construct; its not a proper sequence type.
Not really
The above examples are seldom needed in Python because we have one
general method to repeatedly split a sequence into head and tail.
it = iter(iterable) # 'it' now represents the sequenced iterable
head = next(it) # 'it' now represents the tail after removing the head
In other words,
No more, or less, explicit than the difference between == and is.
== may be taken to mean identity comparison; 'equals' can only mean one
thing. Of course 'formally' these symbols are well defined, but so is
brainf*ck
Modulo is hardly an obscure operation. What's the remainder...? is a
On the contrary, it is a major point. You want us to change the language
so you can program by Google. Sorry, aint't gonna happen.
On the contrary; I believe I get to decide which points I consider
important. This one, I do not. Sorry for putting it in the first paragraph.
--
On the contrary, it is a major point.
Sorry, but im affraid it is up to ME to decide which point I feel are
important. No, this is a minor point to me, and one that has been
admirably put to rest by pointing out that spelling out the name of the
symbol in google directly leads you to the
The modulus is not the result but one of the arguments: when numbers x
and y are congruent modulo n (stated in terms of the modulo operation:
x mod n = y mod n), the modulus is n. A word for x mod n is remainder.
I agree about the obscurity of using the percent sign as the operator.
A quick
By the way...
Is there any particular reason why some of my replies do not show up
on groups.google, and some of them do not show up on mail.python.org?
Sorry to annoy people with reposting, but im going to be forced to do
some of that until this is cleared up
--
No more, or less, explicit than the difference between == and is.
== may be taken to mean identity comparison; 'equals' can only mean
one
thing. Of course 'formally' these symbols are well defined, but so is
brainf*ck
Modulo is hardly an obscure operation. What's the remainder...? is a
I personally quite like them, but I would like them to be more general.
It already is. The *target can be anywhere in the sequence.
Im not sure if this is a genuine understanding, or trollish
obtuseness.
Yes, the target can be anywhere in the sequence. And yes, the
resulting list can
They recognize modular arithmetic but for some reason insist that
there is no such _binary operation_. But as I said, I don't understand
their concern. (Except the related concern about some programming
languages, not Python, where the remainder does not behave well with
respect to division.)
On Dec 12, 7:09 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Mon, Dec 12, 2011 at 5:21 AM, Eelco hoogendoorn.ee...@gmail.com wrote:
You cannot; only constructors modelling a sequence or a dict, and
only
in that order. Is that rule clear enough?
The dict constructor can receive either
False.
I stand corrected.
Or are you saying that only classes specifically derived from list,
tuple, or dict should be considered, and custom containers that are
not derived from any of those but implement the correct protocols
should be excluded? If so, that sounds less than ideal.
That
To get back on topic a little bit, lets get back to the syntax of all
this: I think we all agree that recycling the function call syntax is
less than ideal, since while it works in special contexts like a
function signature, its symmetric counterpart inside a function call
already has the meaning
On Dec 12, 8:05 pm, Eelco hoogendoorn.ee...@gmail.com wrote:
To get back on topic a little bit, lets get back to the syntax of all
this: I think we all agree that recycling the function call syntax is
less than ideal, since while it works in special contexts like a
function signature, its
Im not sure if this is a genuine understanding, or trollish
obtuseness.
If you are referring to what I write, it is based on genuine
understanding of Python.
This is getting 'interesting'. In a way. I meant to write
'misunderstanding', as I think the context made quite clear. So again
this
Throwing an idea for a PEP out there:
It strikes me that the def func(*args, **kwargs) syntax is rather
unpytonic. It certainly did not have that 'for line in file' pythonic
obviousness for me as a beginner. Plus, asterikses are impossible to
google for, so finding out what exactly they do
Yes, that's just a strict keywordification of the * and ** symbols.
The same argument could be made for eliminating the standard algebraic
+ operator and replacing it with a keyword __add__. I don't think
that's worthwhile.
Well, its not quite the same in the sense that algebraic operators
As for syntax; what about coopting/integrating with the function
annotation syntax?
so:
def func(args: list, kwargs: attrdict)
and correspondingly in the function call?
a, b:tuple = someiterable?
I guess a rule that interprets every function argument annotated as a
subclass of list or dict
No more so than any other form of punctuation. Plus and minus + - may be
so common that just about everyone knows it, but how about | == @ % and
even . (dot)? None of these things will be obvious to newbies who have
never programmed before. Oh well.
Some things you just have to learn.
There are other means of finding information than Google. Really.
This is really only a very minor point in my argument, so I dont want to
put the focus on this.
But really, no.
Googling 'myprogramminglanguage conceptimtryingtofigureout' is my first,
second and third line of defence. Yes,
95 matches
Mail list logo
