e magical variables H,
beta, r and V are. And why import solve when you aren't using it?
Curious readers that aren't very good at matrix math, like me, should
still be able to follow your logic. Even if it is just random data,
it's better than nothing!
2014-04-08 12:23 GMT+02:00 Sturla Molden :
> Björn Lindqvist wrote:
>
>> import numpy as np
>> from numpy.linalg import inv, solve
>>
>> # Using dot function:
>> S = np.dot((np.dot(H, beta) - r).T,
>>np.dot(inv(np.dot(np.dot(H, V), H.T)), np.d
2014-04-08 14:52 GMT+02:00 Nathaniel Smith :
> On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist wrote:
>> 2014-04-07 3:41 GMT+02:00 Nathaniel Smith :
>>> So, I guess as far as I'm concerned, this is ready to go. Feedback welcome:
>>> http://legacy.python.org/dev/p
2014-04-09 17:37 GMT+02:00 Nathaniel Smith :
> On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist wrote:
>> 2014-04-08 14:52 GMT+02:00 Nathaniel Smith :
>>> On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist wrote:
>>>> 2014-04-07 3:41 GMT+02:00 Nathaniel Smith :
&
It's not only about what people find intuitive. Why care about them?
Most persons aren't programmers. It is about what application
developers find useful too. I have often needed to calculate month
deltas according to the proposal. I suspect many other programmers
have too. Writing a month add func
2009/9/28 James Y Knight :
>> People building their own Python version will usually also build
>> their own extensions, so I don't really believe that the above
>> scenario is very common.
>
> I'd just like to note that I've run into this trap multiple times. I built a
> custom python, and expected
2009/11/6 Raymond Hettinger :
> [me]
>>
>> Why not write a short, fast get_first() function for your utils directory
>> and be done with it?
>> That could work with sets, mappings, generators, and other containers and
>> iterators.
>> No need to fatten the set/frozenset API for something so trivial
> I know the .desktop files have become fairly standard, but are these our
> responsibility or does that rest with the distributions/integrators? (I'm
> not objecting, but I'm not sure what the right thing really is since Python
> is an interpreter, not a desktop application.)
The same anal argum
On 8/2/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > In all my programming so far I've found
> > numerous uses for round-to-int, and exactly
> > zero uses for round-binary-float-to-decimal-
> > places. So from my point of view, the YAGNI
> > applies to the *current* behavour
> If there are "rampant criticisms" of the Python docs, then those that
> are complaining should take specific examples of their complaints to the
> sourceforge bug tracker and submit documentation patches for the
> relevant sections. And personally, I've not noticed that criticisms of
> the Pytho
On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> > It would be terrific if you gave us some clue about what is wrong in
> > PEP355, so
> > that the next guy does not waste his time. For instance, I find PEP355
> > incredibly good for
On 10/28/06, Talin <[EMAIL PROTECTED]> wrote:
> BJörn Lindqvist wrote:
> > I'd like to write a post mortem for PEP 355. But one important
> > question that haven't been answered is if there is a possibility for a
> > path-like PEP to succeed in th
Is even more syntactic sugar really what Python really needs?
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mai
> When Python's import machinery is initialized, the oldlib package is
> imported. Inside oldlib there is a class called ``OldStdlibLoader``.
> This class implements the PEP 302 interface and is automatically
> instantiated, with zero arguments. The constructor reads all the
> ``.mv`` files from
(This might be a silly question..)
In the dev stdlib reference there are lots of pages in which all text
is in italics. Such as all chapters after chapter 18. Is it supposed
to be that way? It looks quite ugly.
--
mvh Björn
___
Python-Dev mailing list
On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The range of datetime objects far exceeds that of the current Unix
> > timestamp. Given that the range of current (32-bit) Unix timestamps is
> > approximately 1970 to 2038, What wo
On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > On 3/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 3/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > >
On 3/11/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > I've another idea. Date and datetime objects are compared by date. The
> > date object for a given date is always smaller than the datetime for the
> > same day - even for midnight.
>
On 3/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote:
> >Phillip J. Eby schrieb:
> > > This backwards-incompatible change is therefore contrary to policy and
> > > should be reverted, pending a proper transition plan for the change
> > > (such a
On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> I have no problems with Python being untyped. But I want that error
> stack traces provide some useful information as possible with reasonable
> effort and that errors happen as early as possible. In particular, stack
> trace should mention
> def cat(x): return x
>
> def multimap(func, s, n=2):
> assert n > 0, "n must be positive"
> return (map(func, seq)
> if n == 1 else
> map(lambda x: multimap(func, x, n-1),
> seq))
>
> def multifilter(func, s, n=2):
> return multimap(lambda x: fi
> > IMO that pair of examples shows clearly that, in this application,
> > reST is not an improvement over LaTeX in terms of readability/
> > writability of source. It's probably not worse, although I can't help
> > muttering "EIBTI". In particular I find the "``'...'``" construct
> > horribly un
> > In your examples, I think the ReST version can be cleaned up quite a
> > bit. First by using the .. default-role:: literal directive so that
> > you can type `foo()` instead of using double back quotes and then you
> > can remove the redundant semantic markup. Like this:
>
> I've already assign
On 5/24/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > As in the
> > above example, the use of backticks can be signal to the document
> > processor that the enclosed text should be examined for identifiers and
> > other Python syntax.
>
> Does this mean it's time for "pyST" -- Python
Patches are applied once, but thousands of people read the code in the
standard library each month. The standard library should be as
readable as possible to make it as easy as possible to maintain. It is
just good software development methodology.
Many parts of the standard library are arcane an
The threading module contains buggy code:
class Thread(_Verbose):
...
def start(self):
assert self.__initialized, "Thread.__init__() not called"
assert not self.__started, "thread already started"
...
If you run such code with python -O, weird stuff may happen when you
On 6/1/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> Changes in general are a source of risk; they have to be considered carefully.
> We've seen too many cases in which a change was thought to be safe, but broke
> something for someone. Avoiding style-only changes helps avoid introducing
> p
Here is a review of some patches:
* [ 1673759 ] '%G' string formatting doesn't catch same errors as '%g'
This patch is done, has been reviewed and works as advertised. Just
needs someone to commit it I think.
* [ 1100942 ] datetime.strptime constructor added
Doesn't apply cleanly, emits compile
It is fantastic! Totally super work. I just have one small request;
pretty please do not set the font. I'm very happy with my browsers
default (Verdana), and Bitstream Vera Sans renders badly for me.
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@p
On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> How about making IOError, OSError and EnvironmentError all aliases for
> the same thing? The distinction is really worthless historical
> baggage.
Wouldn't it also be nice to have some subclasses of IOError like
FileNotFoundError, IOPermiss
On Sat, Jun 14, 2008 at 11:39 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Some reasons why ordered dicts are a useful feature:
And for metaclasses or for LRU caches or for removing duplicates in a
list while maintaining order. I think that the name ordereddict would
be more readable though, a
One thing i think it would be useful for in the real world is for
unittesting extension modules. You cant profitably write unit tests
for segfaults because that breaks the test harness. In situations like
those, recovering would be likely (caveat emptor of course).
2008/12/10, Adam Olsen <[EMAIL
I'd like to help develop Python for fun and profit and I've heard that
posting patch reviews to python-dev is a good way to contribute. So
here goes:
PATCH REVIEW: [ 1098732 ]
Skip Montanaro has written a patch which makes it so that you can
inspect variable values in tracebacks. IMHO, it is a br
> In contrast, the dowhile solution only takes about 30 seconds to get
> used to. Maybe that idea should follow the path of the genexp PEP, get
> rejected now, and then get resurrected as a bright idea two years from
> now. Or maybe not.
dowhile foo != 42:
<10 lines of body>
foo = rando
*cough*
Would it also be possible for the PEP-maintainers not to accept PEPs
that are obvious jokes unless thedate is April I?
*uncough*
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
do {
cmd = readline()
do_stuff_with_cmd(cmd);
} while (!strcmp(cmd, "quit"));
printf("Bye!");
exit(0);
KISS?
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
> Please don't respond with answers to these questions -- each of them
> is worth several threads. Instead, ponder them, and respond with a +1
> or -1 on the creation of the python-3000 mailing list. We'll start
> discussing the issues there -- or here, if the general sense is not to
> split the li
[nice way to declare properties with "make"]
> Of course, properties are only one of the many possible uses of the
> make statement. The make statement is useful in essentially any
> situation where a name is associated with a namespace. So, for
So far, in this thread that is the only useful us
> > >make_person(=name, =age, =phone, =location)
> >
> > And even with Terry's use case quoted I can't make out what you meant
> > that to do.
>
> I meant it to do the same thing as
>
>make_person(name=name, age=age, phone=phone, location=location)
>
> I come across use cases for this fairl
> > would have thought that the one obvious way to get rid of
> > the wanky feeling would have been to write:
> >
> > def make_person(name, age, phone, location): ...
> >
> > make_person(name, age, phone, location)
>
> This doesn't fly in something like PyGUI, where there
> are literally dozens of
> > And from a syntax perspective, it's a bad idea. x[] is much
> > more often a typo than an intentional attempt to index a
> > zero-dimensional array.
>
> but how often is it a typo?
>
> for example, judging from c.l.python traffic, forgetting to add a return
> statement is a quite common, but I
On 6/23/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> Python is a beautiful simple language with a rich standard library.
> Python has done fine without a switch statement up to now. Guido left it
> out of the original language for some reason (my guess is simplicity).
> Why is it needed now? Wh
> With "var":
>
> var a = 3
> def f():
> var b = 4
> def g():
> var c = 5
> a, b, c = 0, 1, 2 # changes outer a, outer b, and c
> g()
> f()
>
> Now i think this is a little bit weird, because the statement
> "var b = 4" in an outer scope
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
>
> They are indeed an original invention. (One day I looked at the
> similarity between if and while and noticed that there was a use case
> for else after while too.)
>
> The question remains whether Python
I like partition() but maybe even better would be if strings supported
slicing by string indices.
key, sep, val = 'foo = 32'.partition('=')
would be:
key, val = 'foo = 32'[:'='], 'foo = 32'['=':]
To me it feels very natural to extend Python's slices to string
indices and would cover most of par
Something I've noticed from teaching C++ to newbies, is that you
should NOT (never ever) start with "cout << "Hello, world!" << endl;".
You should start with "printf("Hello, world\n");" The cout thingy is
impossible to explain to a newbie because it uses much underlying
"magic" and has a very diffe
> >> While you're at it, maybe we should switch to && and || as well?
> >> That's another thing I always mistype when switching between
> >> languages...
> >
> > You're joking, surely?
>
> for Python 3000, I'd recommend switching to "and then" and "or else" instead
> of the current ambiguous singl
> > I think I'd prefer (if then else ) i.e. no
> > colons.
>
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
That can already be written
> > I did this for my favorite proposal, and ended up with the list shown
> > further down below.
> >
> > I think they all looks great!
> >
> The fact that so few were found in whole of the standard library does
> put the use case into question, though, no? Though I am sure more could
> be found wi
How would the value equality operator deal with recursive objects?
class Foo:
def __init__(self):
self.foo = self
Seems to me that it would take atleast some special-casing to get
Foo() == Foo() to evalute to True in this case...
--
mvh Björn
_
> > Have you studied wikipedia's approach? It's multi-layered and worth
> > learning from (start with their FAQ on editing).
> >
> > (And by the way, I am *not* advocating writing the docs as one big
> > wikipedia -- only the user commentary.)
>
> to clarify, I'm advocating maintaining the docs via
and's PEP 324, many thanks to him.
#
PEP: XXX
Title: path - Object oriented handling of filesystem paths
Version: $Revision: $
Last-Modified: $Date: 2006-01-24 19:24:59 +0100 (Sat, 29 Jan 2005) $
Author: Björn Lindqvist <[EMAIL PROTE
My comments on the issues. It was easier this way than trying to reply
on every message individually.
Inheritance from string (Jason)
This issue has been brought up before when people were discussing the
path module. I think the consensus is that, while the inheritance
isn't pure, practicality be
This seems to be the only really major issue with the PEP. Everything
else is negotiable, IMHO. But the string inheritance seem to be such a
critical issue it deserves its own thread. I have tried to address all
criticism of it here:
Really, it is the same arguments that have been rehashed over an
I think that everything that can be said aboud __div__() has already
been said. But this argument was really convincing:
[Tony Meyer]
> The vast majority of people (at least at the time) were either +0 or
> -0, not +1. +0's are not justification for including something.
There is no clear consens
[M.-A. Lemburg]
> I don't see why this is critical for the success of the Path
> object. I agree with Thomas that interfaces should be made
> compatible to Path object.
See the steps I mentioned. Unless step #1 is completed there is no way
to make the following code work:
open(Path("foobar"))
> > See the steps I mentioned. Unless step #1 is completed there is no way
> > to make the following code work:
> >
> > open(Path("foobar"))
> >
> > Well, there is one alternative which is:
> >
> > open(Path("foobar").tostring())
> >
> > And that is a Java-esque workaraound that I think noo
I've submitted an updated version of the PEP. The only major change is
that instead of the method atime and property getatime() there is now
only one method named atime(). Also some information about the string
inheritance problem in Open Issues. I still have no idea what to do
about it though.
--
On 2/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I won't even look at the PEP as long as it uses / or // (or any other
> operator) for concatenation.
That's good, because it doesn't. :) http://www.python.org/peps/pep-0355.html
--
mvh Björn
___
P
59 matches
Mail list logo
