On Jan 23, 6:54 pm, Wanderer 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 package?
>
> Thanks
On Jan 27, 12:04 am, Wanderer wrote:
> On Jan 26, 2:56 pm, Wanderer wrote:
>
> > On Jan 25, 1:12 pm, Wanderer wrote:
>
> > > I found it it is in the stsci package.
>
> > > On Jan 24, 11:36 am, Eelco wrote:
>
> > > > Either way, if I un
On Feb 12, 7:41 am, Steven D'Aprano 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 technique to improve the approximation.
On Apr 10, 3:36 am, Kiuhnm 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 function?
>
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 kin
> 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 whit
> 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
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
--
http://mail.python.org/mailm
> 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 con
> 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 divisi
On Dec 12, 7:09 pm, Ian Kelly wrote:
> On Mon, Dec 12, 2011 at 5:21 AM, Eelco 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 a sequence or
> 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.
T
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 o
On Dec 12, 8:05 pm, Eelco 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 symmetric
> > 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 agai
On Dec 13, 1:27 am, alex23 wrote:
> On Dec 13, 3:12 am, Eelco 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 wrote:
> On Mon, Dec 12, 2011 at 11:51 AM, Eelco 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 wrote:
> On Mon, Dec 12, 2011 at 4:40 PM, Eelco 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
On Dec 13, 3:43 am, Steven D'Aprano 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 me
> > 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
> 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 annotat
On 13 dec, 11:15, Arnaud Delobelle wrote:
> On 13 December 2011 09:50, Eelco 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, it is
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 if
On 13 dec, 12:28, Steven D'Aprano 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 creato
On 13 dec, 12:13, Steven D'Aprano wrote:
> On Tue, 13 Dec 2011 01:15:46 -0800, Eelco wrote:
> > On Dec 13, 3:43 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Mon, 12 Dec 2011 04:21:15 -0800, Eelco wrote:
> >> >> No mo
On 13 dec, 14:14, Chris Angelico wrote:
> On Tue, Dec 13, 2011 at 11:47 PM, Eelco 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 l
On Dec 13, 8:11 pm, Cameron Simpson wrote:
> On 13Dec2011 00:30, Eelco wrote:
> | On Dec 13, 1:27 am, alex23 wrote:
> | > On Dec 13, 3:12 am, Eelco wrote:
> | > > But to relate it to the topic of this thread: no, the syntax does not
> | > > allow one to se
On Dec 13, 7:15 pm, Ian Kelly wrote:
> On Tue, Dec 13, 2011 at 1:44 AM, Eelco 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 a problem, beca
On Dec 14, 4:18 am, Steven D'Aprano 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 whatever some dead guy
> > s
On 14 dec, 09:56, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
> > On Mon, 12 Dec 2011 09:29:11 -0800, Eelco wrote:
>
> > [quoting Jussi Piitulainen ]
> > >> They recognize modular arithmetic but for some reason insist that
> > >> there is no
On 14 dec, 12:55, Arnaud Delobelle wrote:
> On 14 December 2011 07:49, Eelco wrote:
> > On Dec 14, 4:18 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> > They might not be willing to define it, but as soon as we programmers
> >> > d
On 14 dec, 13:22, Jussi Piitulainen 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 remainder a bi
On Dec 14, 1:38 pm, Steven D'Aprano 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 mathematically,
'Kindof' off-topic, but what the hell :).
On Dec 14, 5:13 pm, Arnaud Delobelle wrote:
> On 14 December 2011 12:33, Eelco wrote:
> > On 14 dec, 12:55, Arnaud Delobelle wrote:
> >> On 14 December 2011 07:49, Eelco wrote:
> >> > On Dec 14, 4:18
On Dec 15, 4:43 am, rusi wrote:
> On Dec 14, 10:15 pm, Eelco wrote:
>
> > 'Kindof' off-topic, but what the hell :).
>
>
> We keep having these debates -- so I wonder how off-topic it is...
> And so do famous
> CSists:http://research.microsoft.com/en-us/um/p
On Dec 15, 11:47 am, Robert Kern 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 is not a bin
On Dec 15, 11:56 am, rusi wrote:
> On Dec 15, 2:44 pm, Eelco 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 recursive (
On Dec 16, 3:58 am, MRAB wrote:
> On 16/12/2011 02:14, alex23 wrote:
>
> > Eelco 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, c
On Dec 16, 6:30 am, alex23 wrote:
> On Dec 16, 3:01 pm, Chris Angelico 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 more fitting name -
On 16 dec, 18:38, rusi wrote:
> On Dec 16, 3:25 pm, Eelco 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)
Heh. Well at
On Dec 17, 12:49 am, Gregory Ewing
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
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 ast
On Dec 17, 6:18 pm, Chris Angelico wrote:
> On Sun, Dec 18, 2011 at 4:14 AM, Roy Smith 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 operators * and **.
>
> ChrisA
On Dec 18, 1:59 am, Steven D'Aprano 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 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 initial reactio
On Dec 18, 6:33 am, 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 18 dec, 18:03, Steven D'Aprano 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 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
foo(@args, @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,
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 meet
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.
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 was
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: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 no
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.
>
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 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
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 whitespac
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 c
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 togeth
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?
>
> >
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 separat
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
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.
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
> >
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
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
>
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)&
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 comm
On Dec 27, 6:59 am, Carl Smith wrote:
> On Dec 20, 10:58 am, Andrea Crotti 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 experienced with the command
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 preferr
On Dec 27, 6:53 pm, Lie Ryan 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 fo
On Dec 27, 9:04 pm, Rick Johnson wrote:
> On Dec 27, 1:45 pm, Eelco wrote:
>
> > On Dec 27, 6:53 pm, Lie Ryan wrote:
> > > On 12/27/2011 10:41 PM, Eelco wrote:
> > > Before using VIM, I used to use gedit
>
> Eelco, please don't get offended, but can y
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:
>
> [...]
>
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
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, 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
> >> (
On Dec 28, 2:56 am, Rick Johnson wrote:
> On Dec 27, 3:44 pm, Eelco 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 to waste on you
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 l
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 propo
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
> 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,
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 t
On 13 jan, 20:04, Ethan Furman 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 that if
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 = np.loa
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 mor
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 operator
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 a
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.
Y
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,
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, ne
> 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...?" i
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.
--
http://mail.pyt
> 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 inf
95 matches
Mail list logo
