2014-04-09 17:37 GMT+02:00 Nathaniel Smith n...@pobox.com:
On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist bjou...@gmail.com wrote:
2014-04-08 14:52 GMT+02:00 Nathaniel Smith n...@pobox.com:
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist bjou...@gmail.com wrote:
2014-04-07 3:41 GMT+02:00
2014-04-08 14:52 GMT+02:00 Nathaniel Smith n...@pobox.com:
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist bjou...@gmail.com wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com:
So, I guess as far as I'm concerned, this is ready to go. Feedback welcome:
http://legacy.python.org
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!
--
mvh/best regards Björn Lindqvist
2014-04-08 12:23 GMT+02:00 Sturla Molden sturla.mol...@gmail.com:
Björn Lindqvist bjou...@gmail.com 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.dot(H, beta) - r
2009/11/6 Raymond Hettinger pyt...@rcn.com:
[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
2009/9/28 James Y Knight f...@fuhm.net:
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
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
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, and
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,
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
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
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
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 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-structured
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 unreadable
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 assigned the
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: filter(func,
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 that
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 as
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.
I really
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 would the
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:
The range of datetime objects far exceeds that of the current Unix
(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
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 the
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:
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 the future? If so, does the path-object
implementation have
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 my own path
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 Python docs
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 of round()!
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 argument
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? What
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 haven't
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 potential
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 fairly frequently,
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 list.
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:
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
___
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.
[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))
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
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
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
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 a
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
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 with a more
I think I'd prefer (if expr then expr else expre) 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
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 single-keyword versions.
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 different
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
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 would be
*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 Bjrn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
do:
block
until cond
Written like this it is not very obvious that the 'unil' is part of
the do-until suite. I also imagine it to be difficult to parse and it
breaks the rule that suites end when there is a dedentation. So, IMHO
using an indented 'until' is the least evil of a
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.
nothing about foo here
dowhile foo != 42:
10 lines of
do:
body
until cond
But I'm sure that has problems too.
[Raymond Hettinger]
That looks nice to me.
[Nick Coghlan]
And this could easily be extended to allow code both before and after
the 'until', giving a fully general loop:
do:
Guido How many try/finally statements have you written inside a loop?
Guido In my experience this is extrmely rare. I found no
Guido occurrences in the standard library.
[Skip again]
How'd we start talking about try/finally?
Because it provides by far the dominant use
RSMotD (random stupid musing of the day): so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
Would it be useful for anything other than mutex-locking? And wouldn't
it be better to make a function of the block
Not sure this is pertinent but anyway: any and all are often used
as variable names. all especially often and then almost always as a
list of something. It would not be good to add all to the list of
words to watch out for. Also, all is usually thought of as a list of
(all) things. In my mind it
I would LOVE for **kwargs to be an ordered dict. It would allow me to
write code like this:
.class MyTuple:
.def __init__(self, **kwargs):
.self.__dict__ = ordereddict(kwargs)
.
.def __iter__(self):
.for k, v in self.__dict__.items():
.yield v
.
.t = MyTuple(r
58 matches
Mail list logo
