CentOS 6.5 / SPEC file
I have been trying to compile an RPM manually using the SPEC file that is
contained in the source tarball from Python.org's website. I have tried
multiple versions and they all seem to fail. I have tried the latest 3.4.0
release, 3.3.5 release, and 3.2.5 release. It appears the SPEC file
contained in the Misc/RPM directory is broken.
I am seeing the error:
+ '[' '!' -z 2.6 ']'
+ cd /builddir/build/BUILDROOT/python2.6-3.3.5-1pydotorg.x86_64/usr/bin
+ mv pydoc pydoc.old
mv: cannot stat `pydoc': No such file or directory
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.yqWO6C (%install)
line 71: buildprereq is deprecated: BuildPrereq: expat-devel
line 72: buildprereq is deprecated: BuildPrereq: db4-devel
line 73: buildprereq is deprecated: BuildPrereq: gdbm-devel
line 74: buildprereq is deprecated: BuildPrereq: sqlite-devel
line 91: prereq is deprecated: Prereq: python2.6 = %{PACKAGE_VERSION}
line 122: prereq is deprecated: Prereq: python2.6 =
%{PACKAGE_VERSION}-1pydotorg
Bad exit status from /var/tmp/rpm-tmp.yqWO6C (%install)
It seems to give me this error regardless of what version of Python I am
trying. Is there a good website that contains maybe a more correct version
of the SPEC file for CentOS 6.x? Any help would be greatly appreciated.
Devin Acosta
--
https://mail.python.org/mailman/listinfo/python-list
sharding research with pyshards
If anyone is interested in sharding or horizontal partitioning, I've started an open source project on Google Code with the intent of building a general purpose sharding framework for python using MySQL. If you have an interest in this area of research, please come on over and get involved. http://code.google.com/p/pyshards/ Devin Venable -- http://mail.python.org/mailman/listinfo/python-list
"Exploding" (**myvariable) a dict with unicode keys
So Python can have unicode variable names but you can't "explode" (**myvariable) a dict with unicode keys? WTF? -Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: "Exploding" (**myvariable) a dict with unicode keys
On Oct 3, 1:57 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> "Martin v. Löwis" wrote:
> > Devin wrote:
> >> So Python can have unicode variable names but you can't
> >> "explode" (**myvariable) a dict with unicode keys? WTF?
>
> > That works fine for me.
>
> The OP probably means
>
> >>> def f(a=1): return a
> ...
> >>> f(**{"a": 42})
> 42
> >>> f(**{u"a": 42})
>
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: f() keywords must be strings
>
> Peter
Yes, that's exactly what I mean.
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Exploding" (**myvariable) a dict with unicode keys
On Oct 3, 2:29 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Devin wrote:
> > On Oct 3, 1:57 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> >> "Martin v. Löwis" wrote:
> >>> Devin wrote:
> >>>> So Python can have unicode variable names but you can't
> >>>> "explode" (**myvariable) a dict with unicode keys? WTF?
> >>> That works fine for me.
> >> The OP probably means
>
> >>>>> def f(a=1): return a
> >> ...
> >>>>> f(**{"a": 42})
> >> 42
> >>>>> f(**{u"a": 42})
> >> Traceback (most recent call last):
> >> File "", line 1, in
> >> TypeError: f() keywords must be strings
>
> >> Peter
>
> > Yes, that's exactly what I mean.
>
> Hmm. Why did you say that Python can have unicode variable
> names? In the version you are using, it can't. In Python
> 3.0, it can, but then, you can also use Unicode strings
> as keys in **arguments, in Python 3.0.
>
> Regards,
> Martin
Oh. I read somewhere that UTF-8 variable names we're supported. I
thought I even saw a colleague using Kanji.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python for philosophers
On Sun, May 12, 2013 at 1:17 AM, Steven D'Aprano wrote: > On Sat, 11 May 2013 21:45:12 -0700, rusi wrote: > >> I have on occasion expressed that newcomers to this list should be >> treated with more gentleness than others. And since my own joking may be >> taken amiss, let me hasten to add (to the OP -- Citizen Kant) > > A noble aim, but I have a feeling that "Citizen Kant" is version 2.0 of > 8 Dihedral. > > Of course, I could be wrong. Without benefit of the doubt, kindness is impossible. I would suggest giving newcomers at least that much. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Utility to locate errors in regular expressions
On Fri, May 24, 2013 at 8:58 AM, Malte Forkel wrote: > As a first step, I am looking for a parser for Python regular > expressions, or a Python regex grammar to create a parser from. the sre_parse module is undocumented, but very usable. > But may be my idea is flawed? Or a similar (or better) tools already > exists? Any advice will be highly appreciated! I think your task is made problematic by the possibility that no single part of the regexp causes a match failure. What causes failure depends on what branches are chosen with the |, *, +, ?, etc. operators -- it might be a different character/subexpression for each branch. And then there's exponentially many possible branches. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print")
On Mon, Jun 3, 2013 at 12:34 AM, Dan Sommers wrote: > On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote: > >> With the increase in use of higher-level languages, these days >> Heisenbugs most often appear with multithreaded code that doesn't >> properly protect critical sections, but as you say, with lower-level >> languages uninitialised memory is a common source of them. > > Aside from an I/O caching bug directly affected by calling print or > somefile.write (where somefile is stdout), how else could I create a > Heisenbug in pure Python? The garbage collector can do this, but I think in practice it's ridiculously rare, since __del__ is almost never useful due to its unreliability*. The problem is that the garbage collector can do whatever it wants. For example, in CPython it is called after so many cycles have been created. This allows code and user actions to inadvertently affect the garbage collector, and therefore, the invocation of __del__. If your __del__ does anything that accesses mutable global state also used elsewhere, it's conceivable that the order of someone else's access and __del__'s invocation depends on the GC. One order or the other might be the wrong one which causes a failure. As it happens, the "bt" command in pdb creates a cycle and might trigger the garbage collector, causing __del__ to run immediately, and potentially hiding the failure. This isn't really "pure python" in that Python doesn't even guarantee __del__ is ever called at all, let alone why. It's completely implementation-specific, and not a property of Python the language. -- Devin .. [*] Some people use it as an "unreliable fallback"; this turns their magical autosaving code into an attractive and yet horribly dangerous nuisance. Friends don't let friends use __del__. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Thu, Jun 6, 2013 at 12:24 PM, Rick Johnson wrote: > In Python, if you fail to use the return statement, then Python will return > None, NOT some some value that just happens to be the last line executed in > the function -- Ruby breaks the law of least astonishment. Ruby comes from a tradition where this behavior is not astonishing. Languages do not exist in a vacuum. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
Super OT divergence because I am a loser nerd: On Thu, Jun 6, 2013 at 1:27 PM, rusi wrote: > Yes, all programming communities have blind-spots. The Haskell > community's is that Haskell is safe and safe means that errors are > caught at compile-time. I don't think Haskell people believe this with the thoroughness you describe. There are certainly haskell programmers that are aware of basic theory of computation. > Unfortunately* the halting problem stands. When generalized to Rice > theorem it says that only trivial properties of programs are > algorithmically decidable: > http://mathworld.wolfram.com/RicesTheorem.html > > And so the semantic correctness of a program -- a non-trivial property > -- is not decidable. Just because a problem is NP-complete or undecidable, doesn't mean there aren't techniques that give the benefits you want (decidability, poly-time) for a related problem. Programmers often only or mostly care about that related problem, so it isn't the end of the line just when we hit this stumbling block. As far as undecidability goes, one possibility is to accept a subset of desired programs. For example, restrict the language to not be turing complete, and there is no problem. Another resolution to the problem of undecidability is to accept a _superset_ of the collection you want. This permits some programs without the property we want, but it's often acceptable anyway. A third approach is to attach proofs, and only accept a program with an attached and correct proof of said property. This is a huge concept, vital to understanding complexity theory. It may be undecidable to find a proof, but once it is found, it is decidable to check the proof against the program. Haskell takes something akin to the second approach, and allows errors to exist which would require "too much work" to eliminate at compile time. (Although the type system is a literal case of the first resolution). Python, by contrast, often values flexibility over correctness, regardless of how easy it might be to check an error at compile time. The two languages have different philosophies, and that is something to respect. The reduction to Rice's theorem does not respect the trade-off that Haskell is making, it ignores it. It may be a "pipe dream" to get everything ever, but that's not to say that the entire approach is invalid and that we should ignore how Haskell informs the PL discourse. For some reason both the Python and Haskell communities feel the other is foolish and ignorant, dismissing their opinions as unimportant babbling. I wish that would stop. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Conditional decoration
On Mon, Jun 18, 2012 at 6:49 PM, Emile van Sebille wrote:
> On 6/18/2012 3:16 PM Roy Smith said...
> class myDecorator(object):
> def __init__(self, f):
> self.f = f
> def __call__(self):
> print "Entering", self.f.__name__
> self.f()
> print "Exited", self.f.__name__
I dunno about other people, but I generally avoid class decorators
because they do not behave the way functions do when applied as a
decorator for a method.
This is a decorator taken out of some of my own source code. I was
mostly dicking around with things, as opposed to actually coding. The
docstring was even more ridiculous.
from functools import reduce
def rapply(*args):
"""apply(f, ...) <-> rapply(..., f)"""
return args[-1](*args[:-1])
def condecorator(condition, *decorators):
if condition:
return lambda f: reduce(rapply, reversed(decorators), f)
else:
return lambda f: f
Example usage:
@condecorator(condition,
decorator1,
decorator2)
def decorated(...):
...
equivalent to:
def decorated(...):
...
if condition:
decorated = decorator1(decorator2(decorated))
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why has python3 been created as a seperate language where there is still python2.7 ?
On Mon, Jun 25, 2012 at 11:35 PM, Steven D'Aprano wrote: > There's no real difference between typing print(...) and all the other > functions in Python. Do you lament having to type len(obj) instead of > "len obj" or list(zip(a, b, c)) instead of "list zip a b c"? Surely you mean "list $ zip a b c"? ;) But yes, it's really not a big deal. It's a trivial change, and one that 2to3 can handle really easily. > > Making print a statement in the first place was a mistake, but > fortunately it was a simple enough mistake to rectify once the need for > backward compatibility was relaxed. Hmmm, why is the function so much better than the statement? You like using it in expressions? Or is it that you like passing it in as a callback? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Why has python3 been created as a seperate language where there is still python2.7 ?
On Wed, Jun 27, 2012 at 7:02 AM, Chris Angelico wrote: > Much easier to simply say no. It's also easier to cease developing Python at all. By which I mean: just because something is hard doesn't mean it shouldn't be done. Lots of things Python does are hard, but they make users' lives easier. The question should probably be where developer effort is best spent, not where developers spend the least effort. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 3:28 AM, Ben Finney wrote: > Chris Angelico writes: >> C, SQL, REXX, and many other languages. > > So, languages without strong typing then. In that case, I revise my > statement: I know of no programming language with strong typing that > would give a newcomer to Python the above expectation. OCaml is a language with absurdly strong typing, where a < b < c is equivalent to (a < b) < c. Obviously, this only works if c is a boolean, and if a and b are the same type. Otherwise it is a type error. Also, you claimed earlier that the notion of associative "<" is not founded in mathematical notation. It really depends on whose mathematical notation you use -- there's more than one, you know. For example, it's reasonable to expect < to be left- or right-associative in a system like Rick Hehner's Unified Algebra: http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't specify it as being one or the other, so by default one would assume 'a < b < c' to be nonsensical.) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 8:41 PM, Steven D'Aprano wrote: > On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote: > Sheesh guys. Don't go hunting through the most obscure corners of > mathematics for examples of computer scientists who have invented their > own maths notation. (Which, by your own admission, is under-specified and > therefore incomplete.) Who uses Hehner's "Unified Algebra" notation? > Apart from Hehner, if he even uses it himself. I didn't hunt, I was taught it in university. -- Devin (Of course, it shouldn't be hard to guess who the professor was :) -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 9:28 PM, Steven D'Aprano wrote: > Technically, < in Python is left-associative: a < b < c first evaluates > a, not b or c. But it is left-associative under the rules of comparison > operator chaining, not arithmetic operator chaining. Left-associativity is when a < b < c is equivalent to (a < b) < c. You're talking about evaluation order, which can be different. For example, hypothetically, (a < b) < c could evaluate c first, then b, then a. However, Python always evaluates operands left-to-right. A particular case where this comes into play is the ** operator, which is right-associative but still has a left-to-right evaluation order. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: adding a simulation mode
For what it's worth, this is the reason that Allen Short wrote Exocet. > This way, you can test your code without having to resort to sys.modules > hackery, and you can better factor your applications by separating > configuration and environment concerns from the rest of your code. See: - http://washort.twistedmatrix.com/2011/01/introducing-exocet.html - http://washort.twistedmatrix.com/2011/03/exocet-second-look.html -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: simpler increment of time values?
On Thu, Jul 5, 2012 at 12:57 AM, Jason Friedman wrote: > I have some thoughts on a solution, but first, what is 12:45 plus 12 > hours? What is 12:45 minus 13 hours? Is there anything unusual that can happen for a notion of time that is dateless, timezone-unaware, and DST-free? I would imagine that under these constraints the answers are always 0:45 and 23:45 respectively. Although I guess it doesn't hurt to check. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: 2 + 2 = 5
On Thu, Jul 5, 2012 at 10:34 AM, Laszlo Nagy wrote: >>>> 5+1 > 4 4 + 1 is 5 is 4. (e.g. try 2+3 as well). -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: API design question for dbf.py
On Fri, Jul 6, 2012 at 6:46 PM, Ethan Furman wrote:
> It's checking for equality, not identity.
>>> x = float('nan')
>>> x in [x]
True
It's checking for equality OR identity.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: why greenlet, gevent or the stackless are needed?
On Sat, Jul 7, 2012 at 3:09 AM, self.python wrote: > it there somthing that "yield" can't do > or just it is easier or powerful? couroutine-like generators can't give up control flow unless they are the top level function handled by the coroutine controller thing. For example, we can do this: def foo(): while True: next_value = (yield) print next_value But we can't do this: def yap(): next_value = (yield) print next_value def foo(): while True: yap() If we explicitly say that "yap" can control us, via "yield from" (new in Python 3.3), then we can do something like the above, but this still requires explicit markup. In all other releases of Python, this is impossible. On the other hand, coroutines in greenlet et al can do a coroutine context switch at any point. The upside is that this is more flexible (and does something generators pre-3.3 cannot). The downside is that you now need locking structures to guarantee atomic interactions with a shared resource, whereas with generators you know that you always are the sole thing running, until you do a yield (and unless real threads or greenlet or whatever are involved, of course.) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Interview Questions
On Mon, Jul 9, 2012 at 5:22 PM, Peter wrote: > One of my favourite questions when interviewing - and it was 100% reliable > :-) - "what are your hobbies?" > If the answer included programming then they were hired, if not, then they > went to the "B" list. Woe is the poor college grad, who wants to appear like a well-rounded individual and lists capoeira and gardening, instead. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Sun, Jul 15, 2012 at 9:51 PM, Chris Angelico wrote: >> if bool(obj) and a==b: # Correct! >> if obj and a==b: # Incorrect! > > That still doesn't answer the question of what bool(obj) should do if > obj is not a bool, and why if can't do the exact same thing, since if, > by definition, is looking for a boolean state selector. If can obviously do the exact same thing -- it does, in Python. I don't agree with the angle that Rick is spinning, so let me write my own: By forcing the objects in conditional to be booleans, you are forced to do something to non-booleans to convert them. By doing so, you will help inform the reader what the non-boolean is, which makes it easier for them to figure out the code. For example, instead of "if stack:" or "if bool(stack):", we could use "if stack.isempty():". This line tells us explicitly that stack is a container. Or instead of "if dist:" or "if bool(dist):" we could use "if dist == 0:". This tells us explicitly that stack is a number. Supposedly this makes it easier to read code. It certainly reads more like English! :) As far as I know, the only use of having a polymorphic boolean conversion is reducing the amount of typing we do. Generally objects with otherwise different interfaces are not interchangeable just because they can be converted to booleans, so you wouldn't lose much by being forced to explicitly convert to boolean with something interface-specific. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano wrote: > On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote: > >> For example, instead of "if stack:" or "if bool(stack):", we could use >> "if stack.isempty():". This line tells us explicitly that stack is a >> container. > > isempty is not a container method. Your entire reply is predicated on this idea that I was talking about writing classes with this extra "isempty" method. No. I was talking about having "isempty" be part of the collection interface, and eliminating polymorphic bool conversion. If you were confused, instead of assuming I meant something patently absurd, you should have asked for a clarification. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit conversion to boolean in if and while statements
On Tue, Jul 17, 2012 at 2:25 AM, Steven D'Aprano wrote: > It already is part of the collection interface: it is spelled __nonzero__ > (Python 2) or __bool__ (Python 3), and like all dunder methods, it is > called automatically for you when you use the right syntax: You're still ignoring what I actually said. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, Jul 17, 2012 at 4:45 AM, Lipska the Kat wrote: > Is Python truly OO or is it just one way to use the language. I see some > documentation relating to classes but nothing on instantiation .. in fact > the documentation appears to say that classes are used in a static way e.g > ClassName.method(), and command line scripting is really outside the scope > of other OO languages I have experienced. It doesn't look like you're reading the section on classes: http://docs.python.org/tutorial/classes.html You create a class like this: class MyClass(MySuperclass1, MySuperclass2): # class attributes and methods attr = 3 def method(self): print self.attr You can instantiate it by calling the class, as if it were a function: myinstance = MyClass() You call a method getting the method (myinstance.method), and then calling that as if it were a function. myinstance.method() Polymorphism is "duck typed" -- that is, it's based on the presence/absence of attributes and methods, not on declared interfaces (Python has no interfaces). So, for example, "foo.read()" works on any object bound to the name "foo", as long as it has a read method that takes no parameters. This could be a file-like object, but it could also be something completely different that just happens to have a method by the same name. > Is there a previous discussion in the group that I could read. Man, I dunno, the list archives are impossible to navigate. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Tue, Jul 17, 2012 at 1:07 PM, Terry Reedy wrote: > 'type-bondage' is the requirement to restrict function inputs and output to > one declared type, where the type declaration mechanisms are usually quite > limited. This is interesting, I hadn't expected that sort of definition. So Haskell is not a type-bondage language? (i.e. it lets you write functions that accept any type via parametric polymorphism, or any type that supports an interface via type classes). > How easy was it to write max, or a universal sort in Java? You write obj.compareTo(other) < 0 instead of using obj < other, and your methods only work on objects (that support the comparable interface). Otherwise, no different than Python, I guess. Would Java not be a type-bondage language if everything was an object? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation, inheritance and polymorphism
On Thu, Jul 19, 2012 at 5:01 PM, John Gordon wrote: >> Since the current evidence indicates the universe will just keep >> expanding, it's more of a "deep freeze death..." > > Heat death means *lack* of heat. But it doesn't mean low temperature! The term is agnostic as to what the temperature of the universe will be. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone teach me this?
On Fri, Jul 20, 2012 at 11:15 PM, hamilton wrote: > You are an idiot, or a scammer. Please be nice. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Sudden doubling of nearly all messages
On Sat, Jul 21, 2012 at 2:25 PM, Chris Angelico wrote: > On Sun, Jul 22, 2012 at 4:16 AM, Rick Johnson > wrote: >> It was a nice run Google. We had good times and bad times. A few smiles and >> cries. >> >> LMBTFY > > So, what... you reckon Microsoft is going to be the paragon of > righteousness against the squalor of Google's information-grubbing > tactics? Fascinating. It's happened before. The example that made me really realize this was when my university, the University of Toronto, was considering both Microsoft and Google as mail providers for students last year. They chose Microsoft, to a mass of student responses to the effect of "but Microsoft is Evil!". It turns out that they ended up choosing Microsoft because they gave stronger privacy guarantees. People hold grudges against MS too strongly, and they believe too much in Google's righteousness. They are both big companies that don't necessarily care about you. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Basic question about speed/coding style/memory
On Sat, Jul 21, 2012 at 5:06 AM, Steven D'Aprano wrote: > So there is approximately 0.03 second difference per TWO MILLION > if...else blocks, or about 15 nanoseconds each. This is highly unlikely > to be the bottleneck in your code. Assuming the difference is real, and > not just measurement error, the difference is insignificant. It's probably real. For if-else, the true case needs to make a jump before it returns, but for if-return, there's no jump and the return is inlined. -- Devin > So, don't worry about which is faster. Write whichever is more natural, > easier to read and write. The most important advice. Even when it's a larger difference! :) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On Sun, Jul 22, 2012 at 8:29 PM, Chris Angelico wrote: > On Mon, Jul 23, 2012 at 10:24 AM, Steven D'Aprano > wrote: >> Not quite: they have to be an instance of that class. 8< > Hmm. I would have thought that methods were like all other functions: > they take their arguments and do code with them. Duck typing and all. > I stand corrected, then. On Python 3 you are correct. >>> class A: ... def print(self): ... print(self) ... >>> A.print(2) 2 -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: A thread import problem
On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood wrote: > (2) My hand is forced by Apple no longer supporting Carbon. Among > other aspects of this, Carbon can't be used with 64-bit Python, and > more and more Mac users of VPython want to use 64-bit Python. So there > has to be a version of VPython that is based on Cocoa, but Cocoa is > required to be the primary thread. This requirement, combined with the > absolute requirement that the VPython API cannot be changed, is the > problem I face. I have to turn the architecture inside out, > independent of whether the solution meets all criteria for good Python > programming style. I had exactly this problem with Tkinter on Mac. The API involved "synchronous" calls to update a GUI written in tkinter, which ran in another thread (so e.g. students could call the API from the interactive interpreter). This didn't work on new Mac OS X releases, because Tkinter had to be run in the main thread after some update -- and also because of this deadlock issue with imports (but I didn't know that until later). I ended up solving it by running the Tkinter in the main thread of a different process, which could handle RPC invocations asynchronously, and sending remote invocations via a synchronous RPC library in the parent process. Maybe you can do something similar in your case? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: python package confusion
On Mon, Jul 23, 2012 at 6:02 AM, Lipska the Kat wrote: > The PYTHONPATH ev is set to /home/lipska/python/dev/mods:. > in .bashrc Did you export it? Show us your .bashrc, or the relevant line in it exactly. (And make sure that it isn't defined multiple times). Also adding . to the import search path is probably a bad diea. > lipska@ubuntu:~/python/dev/mods$ test.py > Traceback (most recent call last): > File "./test.py", line 5, in > fib(1000) > NameError: name 'fib' is not defined Neither of the files you described in your email message contain the line "fib(1000)", so you pasted the wrong files. > I also have an empty file __init__.py in the mods directory This only matters if you want to "import mods". -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rﾕ.......ï¾
On Mon, Jul 23, 2012 at 9:52 AM, Henrik Faber wrote: > If you allow for UTF-8 identifiers you'll have to be horribly careful > what to include and what to exclude. Is the non-breaking space a valid > character for a identifier? Technically it's a different character than > the normal space, so why shouldn't it be? What an awesome idea! > > What about × vs x? Or Ì vs Í vs Î vs Ï vs Ĩ vs Ī vs ī vs Ĭ vs ĭ vs Į vs > į vs I vs İ? Do you think if you need to maintain such code you'll > immediately know the difference between the 13 (!) different "I"s I just > happened to pull out randomly you need to chose and how to get it? What > about Ȝ vs ȝ? Or Ȣ vs ȣ? Or ȸ vs ȹ? Or d vs Ԁ vs ԁ vs ԃ vs Ԃ? Or ց vs g? > Or ս vs u? Yes, as soon as we add unicode to anything everyone will go insane and write gibberish. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rﾕ.......ï¾
On Mon, Jul 23, 2012 at 10:40 AM, Henrik Faber wrote: > No, you misunderstood me. I didn't say people are going to write > gibberish. What I'm saying is that as a foreigner (who doesn't know most > of these characters), it can be hard to accurately choose which one is > the correct one. This is especially true if the appropriate keys are not > available on your keyboard. So it makes maintenance of other people's > code much more difficult if they didn't on their own chose to limit > themselves to ASCII. I understand, and agree. But that's not always all that likely a situation. If your company only employs native Arabic speakers, why not use Arabic variable names and Arabic script? You'll get more out of making the language easy to understand for the people that work there, than out of hedging your bets on the off chance that some American will stroll in and be confused. (It is my understanding that, in any case, many non-English companies do their coding in English. That doesn't mean it's a general rule that should be forced on everyone.) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Gender, Representativeness and Reputation in StackOverflow
On Mon, Jul 23, 2012 at 9:30 PM, Steven D'Aprano wrote: >> Leaving aside the point that this is not directly related to Python, my >> opinion is that if the authors will not make past and future papers >> freely available, not even an abstract, they should not ask for valuable >> free data from freely donated time. > > Well of course it is your time and your judgement to make, but in my > opinion even non-free scientific knowledge is better than ignorance. When people boycott a product, it isn't because not having the product is better than having the product. That's clearly untrue: despite the reasons for the boycott, the product has some value. They boycott it because by doing so, they can get something better than or -- they can get . (At least, in theory :) Why settle for a terrible situation, when we could be encouraging people to do better? /me has been paying too much attention to the Elsevier boycott -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: What's wrong with this code?
On Tue, Jul 24, 2012 at 2:23 AM, Mark Lawrence wrote: > strictly speaking Python doesn't have variables, it has names. This will > possibly start a flame war which, by the standards of this ng/ml, will be an > intense conflagration, hence the duck and cover. The two terms are nearly synonymous when one talks about Python (and both are used in the language reference). I mean, what's so "strict" about the way you're speaking? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: python package confusion
On Tue, Jul 24, 2012 at 1:38 AM, Steven D'Aprano wrote: > I don't know about a bad idea or not, but it is certainly redundant, > because Python automatically adds '' (equivalent to '.') to the very > start of the search path. No, it only does that if Python is reading commands from stdin, or if Python was run with the -c option, or maybe some other situations. It doesn't do it if you just run a program, as in "python myfile.py". -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: the meaning of rﾕ.......ï¾
On Mon, Jul 23, 2012 at 12:09 PM, Chris Angelico wrote: > It is, in many places. It's one of the few truly international > holidays. The next nearest, Pi Day, has two different dates (the > American and the European - of course, here in Australia, we celebrate > both). Here in Canada we celebrate Tau day. -- Devin (... I wish.) -- http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt wrote: > What do you think? retort: def foo(): None -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
On Wed, Jul 25, 2012 at 12:05 PM, Chris Angelico wrote: > Simple way of making the iterator display its yielded result. I cannot > imagine any circumstance in which you'd want to map "pass" over > everything. But then, as Teresa said, I'm only one, and possibly I'm > wrong! True. But it might be nice to use pass both in lambdas and regular functions, or to use pass as a variable name. (Unfortunately, these two niceties are somewhat in conflict.) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
On Wed, Jul 25, 2012 at 2:14 PM, Ian Kelly wrote: > You can already use pass (or the equivalent) in a lambda. > > lambda: None This lacks my foolish consistency. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak wrote: > If we want pass(), then why not break() and continue()? And also > def() and class()? for(), while(), if(), with(), we can make them all > callable objects! No, you actually can't. You omit the one control flow statement that could actually be turned into a function, raise. None of the rest could in Python (except class), and one of the rest couldn't in any language (def). -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: from future import pass_function
On Thu, Jul 26, 2012 at 5:42 AM, Chris Angelico wrote: >> You omit the one control flow statement that could actually be turned >> into a function, raise. None of the rest could in Python (except >> class), and one of the rest couldn't in any language (def). > > Well, if/while/for could be functions. So could with, probably. Now, > def would be a little tricky... In Haskell, sure. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
PyCon for students?
Hey guys, I recently saw a post saying that PyCon for students' price was dropped to $100. If you are trying to attract students, why not move PyCon to take place during the summer? As far as I know, summer vs spring makes no difference to any members of the general working population (except for teachers and such, who have the same schedule as students), but for students it's the difference between missing a week of school (or, worse, exams), and being able to do whatever because it's the summer vacation. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie question : gedit as an ide
On Sun, Sep 16, 2012 at 7:52 AM, Mayuresh Kathe wrote: > new to the group, a quick hello to all. :-) > does anyone use gedit as an 'ide' for python development? > if yes, may i know the caveats against using 'idle', 'bpython', etc? bpython isn't an IDE, it's a good interactive interpreter. As for gedit as an editor... it's actually really bad, but fixable if you install plugins. e.g., it doesn't have builtin support for case sensitive / regexp search and so on, but these can be added so that gedit becomes tolerable. In fact, one of gedit's main advantages over many of its similar competitors (in particular I'm thinking of Kate) is that the plugin support is very strong, so if it doesn't do what you want, you can make it do what you want anyway. So, install / enable plugins. Lots of them. Or use an editor designed for programmers first, such as Kate or vim or emacs. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Java singletonMap in Python
On Sun, Sep 23, 2012 at 7:14 PM, Mark Lawrence wrote:
> Purely for fun I've been porting some code to Python and came across the
> singletonMap[1]. I'm aware that there are loads of recipes on the web for
> both singletons e.g.[2] and immutable dictionaries e.g.[3]. I was wondering
> how to combine any of the recipes to produce the best implementation
The word "singleton" usually means "thing with only one item". For
example, {a} is a singleton set containing only a, and with matrices,
any dimension of size one is called a singleton dimension, and so on.
In this case, a singleton map is a map with only one key-value pair,
such as {a:b}.
The singleton design antipattern is not relevant here.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano wrote: > On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: > And a response: > > http://data.geek.nz/python-is-doing-just-fine Summary of that article: "Sure, you have all these legitimate concerns, but look, cake!" -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: #python archives?
On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano wrote: > My google-foo is failing me. Is the #python chatroom on freenode archived > anywhere on the web? #python doesn't have a policy against quiet bots that log channel interaction, but AFAIK there are no up-to-date public logs. As evidence to this, a certain anti-logging freenode user hasn't pestered #python ever since the last logging bot was banned (because of unrelated reasons). Is there any particular reason you want the logs? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano wrote: > On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: > >> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano >> wrote: >>> On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a >>> response: >>> >>> http://data.geek.nz/python-is-doing-just-fine >> >> Summary of that article: >> >> "Sure, you have all these legitimate concerns, but look, cake!" > > Did you read the article or just make up a witty response? If so, you > half succeeded. > > It's more like, "Well, maybe, your concerns *might* be legitimate, but I > don't think so because..." and then he gives half a dozen or more reasons > why Python is in no danger. None of which involve cake, although one of > them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. If we're going to have a serious discussion about the problems Python faces in the future, then the topics that Calvin brings up are relevant. These are problems that, ideally, we would overcome. And I think, to some degree, we are working towards a future where these problems are solved. (Except perhaps the game development one, which is a rather tough problem in a lot of ways.) As people have noted, we do have Kivy, we do have PyPy, we do have PyJS and other such things. The future has possibilities for the problems Calvin mentions to be solved, even if they are problems today. The article that was linked, the response, it doesn't talk about this. When Calvin says that Python has problems with mobile, the article doesn't even say "but Kivy does mobile" -- it says "but Science people love Python!" When Calvin says that Python has problems being done on the web, the article doesn't even say "but PyJS!" (regardless of the problems of relying on a hijacked project), it says "education loves Python!" When Calvin says that Python has failed for game development, the article doesn't try to explain any way that Python is moving to success here, or any way that Calvin's assessment is wrong. Instead, it says, "But The Web loves Python!" There is a pattern here. The pattern is that the article does not actually directly respond to anything Calvin said. It doesn't try to carry a dialogue about concerns about problem areas Python has. It ignores Python's problems, and focuses on its strengths. Charitably, maybe we'd call this a way of encouraging people who are discouraged by the bleaker tone of Calvin's post. And that's valid, if we're worried about morale. Definitely Calvin's post could be -- and has been -- taken the wrong way. It could be taken as a way of saying, "Python is doomed!", even though that isn't something Calvin ever wrote (he appears, from my reading, to be more worried about a stagnating community than a failed language). Under that interpretation, we would want other, more encouraging voices around, talking about ways in which Python is good and will survive. Uncharitably, it's just a way of hiding one's head in the sand, ignoring any problems Python has by focusing on what problems it doesn't have. So that's why I said that the summary is, "but look, cake!". Instead of being a dialogue about improving Python, it's a distraction from the issues Calvin brought up. It brings up strengths, which are also part of Python, but don't have much at all to do with Python's weaknesses, or with what Calvin was talking about. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 12:45 PM, Mark Lawrence wrote: > The article Steven D'Aprano referred to is not a direct response to the > article I referred to, yet your words are written as if it were. May I ask > why? Or have I missed something? Post hoc ergo propter hoc :( -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: test
On Thu, Sep 27, 2012 at 5:28 PM, ForeverYoung wrote: > Please ignore this post. > I am testing to see if I can post successfully. Is there a reason you can't wait until you have something to say / ask to see if it works? You're spamming a large number of inboxes with nothing. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 8:59 PM, alex23 wrote: > On Sep 28, 2:17 am, Devin Jeanpierre wrote: >> Uncharitably, it's just a way of hiding one's head in the sand, >> ignoring any problems Python has by focusing on what problems it >> doesn't have. > > But isn't that what counterpoint is all about? Actually I think it's about the charitable interpretation. Nobody writes an article and says, "I'm going to stick my head in the sand". I do believe the article is trying to provide a counterweight to the gloomy mood set by the first. > Calvin's article > highlighted what he felt were areas that Python isn't successful, > while Tim McNamara's pointed out areas it was. Just because Python > isn't used much in commercial video games doesn't undermine the point > that it's heavily used in education and research. Absolutely. But also, vice versa -- just because Python is a wonderful language for education and research does not mean that its problems in commercial video games are not worth looking at. > Does Python _have_ to be a go-to tool in gaming for it to not be on > its death march? I don't think anyone is arguing it's on a death march, just that there are issues that we downplay but should address to keep a vibrant and diverse community. Or something. I'm pretty sure nobody thinks Python is on a death march. > Or more to the point: rather than just complain about it... It's not > like there aren't active communities that _are_ working in this area: > PyGame, pyglet, Kivy are all projects that can be contributed to. Haha, I wouldn't phrase it as "complaining". Of these, I have mixed feelings. For example, Calvin has concerns that Python isn't so good on mobile because battery usage (or some such thing). I have no experience on mobile development, so no comment there. I intend to use Kivy this weekend actually, so... Maybe this one is very promising! You didn't mention it, but for the browser issue there is PyJS... but we've all heard the issues that project has. Not sure if there are sane alternatives. Perhaps Silverlight? In all cases you end up with output that's rather large. I'm not sure how practical it is, in the end, to use Python. It may just be that the difference in productivity for common web tasks, is tiny enough that the difficulty of setting up an efficient python->JS toolchain is overwhelming. As for pygame and pyglet, and game development, well, those are things. That's a sort of frustrating response for a number of reasons, but I'll keep it to just one: Those have been around for a very long time, and are very stable (to the point where the infrequency of updates sometimes leads to questions as to whether they're even maintained (I think they are)). The situation for using Python for game development is virtually unchanged in the past several years, and it's been failing for the past several years, so these two projects can't fix it. If these are the best we have, barring additional argument we are going nowhere on this front. For what it's worth, I think there are much larger problems in the game development world than how well Python is faring. Open source projects for game development are few and of not-so-amazing quality. > I love using Python and will endeavour to do so wherever I can, but > it's always going to be the case that a language has strengths & > weaknesses that other languages lack. Absolutely! Python will never be perfect. There will always be paths we can take to improve it. And we should always seek to improve it, as long as we stand behind it as a good and useful language compared to the alternatives. On the other hand, I will not use Python "wherever I can". I will use it wherever it makes the most sense to use it. For example, I would write a first person shooter game in C# and Unity 3D, and I would write my AJAX website in Javascript. It's just easier for me that way. Why use Python if it makes my job harder? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: write a regex matches 800-555-1212, 555-1212, and also (800) 555-1212.
On Fri, Sep 28, 2012 at 9:58 PM, Mark Lawrence wrote: > What's the run time speed like? How much memory does it use? Shouldn't you > be using the regex module from pypi instead of the standard library re? > Guess who's borrowed the time machine? O(n), O(1), and I used RE2. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Should one always add super().__init__() to the __init__?
On Sat, Sep 29, 2012 at 1:17 PM, Steven D'Aprano wrote: > No. Only add code that works and that you need. Arbitrarily adding calls > to the superclasses "just in case" may not work: > > > > py> class Spam(object): > ... def __init__(self, x): > ... self.x = x > ... super(Spam, self).__init__(x) > ... > py> x = Spam(1) > Traceback (most recent call last): > File "", line 1, in > File "", line 4, in __init__ > TypeError: object.__init__() takes no parameters That's a good thing. We've gone from code that doesn't call the initializer and leaves the object in a potentially invalid state (silently!), to code that calls the initializer and then fails (loudly). -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: fmap(), "inverse" of Python map() function
On Fri, Oct 5, 2012 at 5:31 PM, Ian Kelly wrote: > On Fri, Oct 5, 2012 at 2:19 PM, vasudevram wrote: >> >> http://jugad2.blogspot.in/2012/10/fmap-inverse-of-python-map-function.html > > Your fmap is a special case of reduce. So is map. def map(f, seq): return reduce( lambda rseq, newpre: rseq.append(f(newpre)) or rseq, seq, []) "X is a special case of reduce" is basically the same as saying "X can be implemented using a for loop". If it's meant as a complaint, it's a poor one. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: fmap(), "inverse" of Python map() function
On Fri, Oct 5, 2012 at 7:24 PM, Ian Kelly wrote: > I realize that. My point is that the function *feels* more like a > variant of reduce than of map. > >> If it's meant as a complaint, it's a poor one. > > It's not. Fair enough all around. Sorry for misunderstanding. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Quickie - Regexp for a string not at the beginning of the line
On Thu, Oct 25, 2012 at 10:00 PM, Ed Morton wrote: > Because there is no solution - there IS no _RE_ that will match a string not > at the beginning of a line. Depending on what the OP meant, the following would both work: - r"^(?!mystring)" (the string does not occur at the beginning) - r"(?!^)mystring" (the string occurs elsewhere than the beginning) [Someone else's interpretation] Both are "regular expressions" even in the academic sense, or else have a translation as regular expressions in the academic sense. They're also Python regexps. So I don't know what you mean. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Fri, Oct 26, 2012 at 2:40 PM, Steven D'Aprano wrote: >> The problem isn't with the associativity, it's with the equality >> comparison. Replace "x == y" with "abs(x-y)> and all your statements fulfill people's expectations. > > O RYLY? > > Would you care to tell us which epsilon they should use? I would assume some epsilon that bounds the error of their computation. Which one to use would depend on the error propagation their function incurs. That said, I also disagree with the sentiment "all your statements fulfill people's expectations". Comparing to be within some epsilon of each other may mean that some things that are the result of mathematically unequal expressions, will be called equal because they are very close to each other by accident. Unless perhaps completely tight bounds on error can be achieved? I've never seen anyone do this, but maybe it's reasonable. > Hint: *whatever* epsilon you pick, there will be cases where that is > either stupidly too small, stupidly too large, or one that degenerates to > float equality. And you may not be able to tell if you have one of those > cases or not. > > Here's a concrete example for you: > > What *single* value of epsilon should you pick such that the following > two expressions evaluate correctly? > > sum([1e20, 0.1, -1e20, 0.1]*1000) == 200 > sum([1e20, 99.9, -1e20, 0.1]*1000) != 200 Some computations have unbounded error, such as computations where catastrophic cancellation can occur. That doesn't mean all computations do. For many computations, you can find a single epsilon that will always return True for things that "should" be equal, but aren't -- for example, squaring a number does no worse than tripling the relative error, so if you square a number that was accurate to within machine epsilon, and want to compare it to a constant, you can compare with relative epsilon = 3*machine_epsilon. I'm not sure how commonly this occurs in real life, because I'm not a numerical programmer. All I know is that your example is good, but shows a not-universally-applicable problem. It is, however, still pretty applicable and worth noting, so I'm not unhappy you did. For example, how large can the absolute error of the sin function applied to a float be? Answer: as large as 2, and the relative error can be arbitrarily large. (Reason: error scales with the input, but the frequency of the sin function does not.) (In case you can't tell, I only have studied this stuff as a student. :P) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 1:12 AM, Dan Loewenherz wrote:
> It seems the topic of this thread has changed drastically from the original
> message.
>
> 1) "while EXPR as VAR" in no way says that EXPR must be a boolean value. In
> fact, a use case I've run into commonly in web development is popping from a
> redis set. E.g.
>
> client = StrictRedis()
> while True:
> profile_id = client.spop("profile_ids")
> if not profile_id:
> break
> print profile_id
>
> In this case, profile_id is "None" when the loop breaks. It would be much
> more straightforward (and more Pythonic, IMO), to write:
>
> client = StrictRedis()
> while client.spop("profile_ids") as profile_id:
> print profile_id
For loops are pythonic. You can do this in Python today:
client = StrictRedis()
for profile_id in iter(lambda: client.spop("profile_ids"), None):
pass
I would like a better iter(), rather than a better while loop. It is
irritating to pass in functions that take arguments, and it is
impossible to, say, pass in functions that should stop being iterated
over when they return _either_ a None or a, say, False.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico wrote:
> while (client.spop("profile_ids") as profile_id) is not None:
> print profile_id
>
> Why is everyone skirting around C-style assignment expressions as
> though they're simultaneously anathema and the goal? :)
Why should these two statements behave differently? :(
with foo() as bar: bar.baz()
with (foo() as bar): bar.baz()
I don't understand why everyone is so attached to this "as" syntax.
It's confusing because it behaves subtly differently than how it works
in "with", and it puts the variable on the wrong side of the
assignment operator.
(I've always been partial to ":=", personally.)
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson wrote:
> Any doco would need to make it clear that no order of operation is
> implied, so that this:
>
> x = 1
> y = (2 as x) + x
>
> does not have a defined answer; might be 2, might be 3. Just like any
> other function call with side effects.
But function calls with side effects _do_ have a defined order of
evaluation. Left to right. And the answer should be 4.
http://docs.python.org/reference/expressions.html#evaluation-order
>>> def set_(d, k, v):
... d[k] = v
... return v
...
>>> d = {}
>>> set_(d, 'x', 1)
1
>>> set_(d, 'y', set_(d, 'x', 2) + d['x'])
4
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 7:41 PM, Dan Loewenherz wrote: -- snip insanity -- > > But this is yucky. I'd much rather have something a bit more clear to the > reader. That's why I said I wanted a better iter, not some equality-overriding object strawman thing. I was thinking more like this: for profile_id in iter(None)(client.spop, "profile_ids"): or alternatively: for profile_id in iter(bool)(client.spop, "profile_ids"): Or perhaps either as keyword arguments (which is the only reason I curried iter). The interesting case for in-place assignment is not here. This is a trivial case. It's in cases like this: while True: x = foo(bar()) if x is None: break if x % 2 == 0: break print x Imagine doing that with iter. :) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 7:56 PM, Cameron Simpson wrote: > No. Separate _expressions_ are evaluated left to right. > > So this: > > f(1), f(2) > > calls "f(1)" first, then "f(2)". But this: > > f(1) + f(2) > > need not do so. Counter-documentation welcomed, but the doco you cite > does not define an order for the second example above. Actually, it does. Both f(1) and f(2) are separate (sub-)expressions in f(1) + f(2). More to the point, it gives the following example: In the following lines, expressions will be evaluated in the arithmetic order of their suffixes: ... expr1 + expr2 * (expr3 - expr4) I sympathize with your concern, though. Order of evaluation is very bitey, and it's better to be safe than sorry. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On Fri, Oct 26, 2012 at 8:18 PM, Steven D'Aprano wrote: >> I would like a better iter(), rather than a better while loop. It is >> irritating to pass in functions that take arguments, and it is >> impossible to, say, pass in functions that should stop being iterated >> over when they return _either_ a None or a, say, False. > > Write a trivial helper function. Not everything has to be a one-liner or > a built-in. You are missing the point. I was suggesting that the use case of new syntax might be satisfied instead by new functions, which are clearly preferable to new syntax from the perspective your rebuttal comes from. Indeed, one could write those helper functions, and use them, without any changes to Python being made at all! -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Immutability and Python
On Mon, Oct 29, 2012 at 12:46 PM, Paul Rubin wrote: > andrea crotti writes: >> Also because how doi I make an immutable object in pure Python? > > Numbers in Python are already immutable. What you're really looking for > is a programming style where you don't bind any variable more than once. No, they were looking for a way to create classes whose instances are immutable. Also, immutability has nothing to do with the presence or lack of for loops. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: What are the minimum requirements to get a job in?
On Fri, Dec 14, 2012 at 1:13 AM, rusi wrote: > On Dec 14, 8:33 am, Dave Angel wrote: >> Do you know any one computer language thoroughly? Or just a little of >> many languages? > > There is a quote by Bruce Lee to the effect: > I am not afraid of the man who knows 10,000 kicks > I am afraid of the man who has practised 1 kick 10,000 times It's worth pointing out that kicks stay relevant for your entire life. Unfortunately, many programming languages don't. I guess the next metaphor would be stock investments and diversification. Point is, don't just practice one kick. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 2:32 PM, Duncan Booth wrote: > The problem with your idea is that it breaks compatability with other non- > Python regular expression engines. Python didn't invent the (?...) syntax, > it originated with Perl. > > Try complaining to a Perl group instead. The Perl folks didn't like it either: http://en.wikipedia.org/wiki/Perl_6_rules -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 12:16 PM, Rick Johnson wrote: > In particular i find the "extension notation" syntax to be woefully > inadequate. You should be able to infer the action of the extension > syntax intuitively, simply from looking at its signature. This is nice in theory. I see no reason to believe this is possible, or that your syntax is closer to this ideal than the existing syntax. Perhaps you should perform some experiments to prove intuitiveness? Science is more convincing than insults. Also, the "!" in negative assertions doesn't stand for "not equal" -- matches aren't equality. It stands for "not". It's the "=" that's a misnomer. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 7:14 PM, Rick Johnson wrote: > It is germane in the fact that i believe PyParsing, re, and my new > regex module can co-exist in harmony. If all you're going to change is the parser, maybe it'd be easier to get things to coexist if parsers were pluggable in the re module. It's more generally useful, too. Would let re gain a PyParsing/SNOBOL like expression "syntax", for example. Or a regular grammar syntax. Neat for experimentation. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: import fails in non-interactive interpreter
On Wed, Jan 25, 2012 at 9:25 PM, Brian wrote:
> Under what situations would a module be available to through the
> interactive interpreter but not the non-interactive?
I don't know if it matches your situation, but one such case is this:
The interactive interpreter (and the interpreter with the -c flag) add
the current working directory ('') to the module import search path
(sys.path). Regular python execution does not. So modules in the
current working directory can always be imported from the interactive
interpreter, but not necessarily if you run python on a source file.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Constraints -//- first release -//- Flexible abstract class based validation for attributes, functions and code blocks
Ooh, runtime turing-complete dependent-types. :) I'm not sure if you're aware of the literature on this sort of thing. It's nice reading. A library such as this that's designed for it could be used for static checks as well. Probably deserves a better name than "constraintslib", that makes one think of constraint satisfaction. On Thu, Jan 26, 2012 at 2:36 PM, Nathan Rice wrote: > Design by contract style preconditions, postconditions and invariants are also > supported, and can be used either as context managers or function decorators:: Any way to get them to raise a different error, such as ValueError (in particular for preconditions)? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Constraints -//- first release -//- Flexible abstract class based validation for attributes, functions and code blocks
On Thu, Jan 26, 2012 at 3:24 PM, Nathan Rice wrote: > One of the nice things about Haskell is that the language is designed > in a way that is conducive to > proving things about your code. A side benefit of being able to prove > things about your code is that > in some cases you will be able to derive code just from well crafted > specifications (like higher order > Prolog). This isn't a game changer yet, but with advances in theorem > proving software and a thoughtful > language ontology, I could see it taking off very soon. Dijkstra was > focused primarily on this area for the > last 25 years of his life. May I suggest a look at languages such as ATS and Epigram? They use types that constrain values specifically to prove things about your program. Haskell is a step, but as far as proving goes, it's less powerful than it could be. ATS allows you to, at compile-time, declare that isinstance(x, 0 <= Symbol() < len(L)) for some list L. So it might align well with your ideas. >> Probably deserves a better name than "constraintslib", that makes one >> think of constraint satisfaction. > > As you can probably tell from my other projects, I'm bad at coming up > with snappy names. I'm bad at doing research on previous projects ;) I'm sure another name will come up as the goals mature/solidify. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: speaking at PyCon
On Mon, Jan 30, 2012 at 6:48 PM, Roy Smith wrote: > Wow. As somebody who has given plenty of talks, I can tell you this is an > awesome checklist (and most of it not specific to PyCon). > > Let me add one suggestion -- never, ever, ever, type a URL into a browser > connected to the internet in front of a live audience. You never know when > you're going to make a typo and something *totally* not what you expected > will fill the screen. If you absolutely insist on ignoring the good advice > about not doing live demos, at least bookmark your urls and click on the > bookmark. DAMHIKT. I have to ask... was it python.com? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Mon, Jan 30, 2012 at 7:00 PM, Steven D'Aprano wrote: > On Mon, 30 Jan 2012 12:41:00 -0500, Charles Yeomans wrote: > >> To catch more than one exception type in an except block, one writes >> >> except (A, B, C) as e: >> >> I'm wondering why it was decided to match tuples, but not lists: >> >> except [A, B, C] as e: > > Simplicity. > -snip- I agree with the snipped, but would also like to add that regardless of why it might be so, tuples do appear to be the canonical type for collections that need to be typechecked -- not just for except; it's a consistent thing that if you're going to do something with "X, or a bunch of X's", then it's either an X or a tuple of X's. For example, string formatting with % works this way, as does isinstance(a, X). -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: except clause syntax question
On Tue, Jan 31, 2012 at 11:23 AM, Charles Yeomans wrote: > > On Jan 31, 2012, at 9:51 AM, Steven D'Aprano wrote: > >> On Tue, 31 Jan 2012 08:57:31 -0500, Charles Yeomans wrote: >> >>> I don't think of a tuple as a container, and I don't think it a >>> misunderstanding on my part to think this. >> >> Well, it is a misunderstanding, because tuples ARE containers. You might >> as well say "I don't think of boxes as containers". What exactly are they >> if not containers? > > > Tuple is a heterogenous datatype that allows one to define objects ad hoc. > That is to say, a tuple represents a single thing distinct from its > components. For example, suppose you need to represent a location in text by > line number and offset within a line. A tuple object makes it easy to do so > without writing a class having no methods other than a constructor. Here, > the components, a line number and an offset, define a new object distinct > from the pieces. > > One can certainly view a tuple as a list, just as one can view a string as a > list of characters, and sometimes that's useful; the Python dictum "there > should only be one way to do it" doesn't imply that there is only one way to > think of it. > > Nor am I the only person who sees such a distinction between tuple and list. Perhaps it'd be useful to look at how the Python language reference defines containers? Quote: Some objects contain references to other objects; these are called containers. Examples of containers are tuples, lists and dictionaries. The references are part of a container’s value. In most cases, when we talk about the value of a container, we imply the values, not the identities of the contained objects; however, when we talk about the mutability of a container, only the identities of the immediately contained objects are implied. So, if an immutable container (like a tuple) contains a reference to a mutable object, its value changes if that mutable object is changed. End quote. (Offtopic: How do I do an external block quote appropriately in an email?) Tuples are most certainly containers, precisely _because_ they're an ad-hoc way to define objects, where the only purpose of the object is to contain the values inside the tuple. But these are just words and it's beside the point. We should talk of things as if the word "container" didn't matter, because I don't think that's what you meant, but neither do I want to put words in your mouth. My interpretation is that you see tuples as an object where you can get meaningfully things by field, rather than just grab arbitrarily from a bag of things. This isn't the only way they are used, see the except statement (hee) and their use as keys in dictionaries. But it is true that their immutable length makes them very well suited to the task of representing product types. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Disable use of pyc file with no matching py file
On Tue, Jan 31, 2012 at 6:55 PM, Terry Reedy wrote: > Q. "How do I make my old model car do something (it cannot do)?" > A. "Get the free new model that has that feature added." > > Of course, there is a cost to giving up the old and familiar and learning > and adjusting to the new, even when it is available gratis. A husband > wearing an old sweater after his wife gives him a new one, and even > retrieving it from the trash when she tosses it out, is a classic (and true) > cartoon joke. It really bothers me that you imagine that there are no other problems than the newness. It's disheartening, because the problems are not that trivial and the world would be better if people were less callous about it, and realized that they exist. Python 3 is not very different from Python 2, as far as humans are concerned semantically/syntactically -- but, hell, just pick any project that uses PyPy, or Jython, or IronPython, or Twisted, or Zope, etc. -- it can be a lot of effort (sometimes infeasibly much) to port something dependent on these things, and it's taken years to get the (smallish) set of dependencies ported that we have now [and we literally paid people to do it, too!], and still many large projects haven't made the transition, and many small projects never will. Anyone that relies on those projects is stuck, and your "free car" metaphor completely ignores the true cost of wasting that much time porting everything for a tiny little feature. Evaluating only the monetary amounts can be misleading as to what the rational decision is (in particular when there are no monetary amounts). The only true notion of cost is the alternatives you sacrifice in making a decision: opportunity cost. The car is not free. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: copy on write
On Wed, Feb 1, 2012 at 10:18 PM, John O'Hagan wrote:
> On Fri, 13 Jan 2012 10:40:47 -0800
> Ethan Furman wrote:
>
>> Steven D'Aprano wrote:
>> > Normally this is harmless, but there is one interesting little
>> > glitch you can get:
>> >
>> >>>> t = ('a', [23])
>> >>>> t[1] += [42]
>> > Traceback (most recent call last):
>> > File "", line 1, in
>> > TypeError: 'tuple' object does not support item assignment
>> >>>> t
>> > ('a', [23, 42])
>
> IMHO, this is worthy of bug-hood: shouldn't we be able to conclude from the
> TypeError that the assignment failed?
It did fail. The mutation did not.
I can't think of any way out of this misleadingness, although if you
can that would be pretty awesome.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Disable use of pyc file with no matching py file
On Wed, Feb 1, 2012 at 2:53 PM, Terry Reedy wrote: > And it bothers me that you imput such ignorance to me. You made what I think > was a bad analogy and I made a better one of the same type, though still > imperfect. I acknowledged that the transition will take years. Ah. It is a common attitude among those that make these sorts of comments about Python 3, and I hadn't read anything in what you said that made me think that you were considering more than the superficial costs of moving. I am sorry that I did not give you the benefit of the doubt. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: SnakeScript? (CoffeeScript for Python)
On Thu, Feb 2, 2012 at 11:30 AM, Paul Moore wrote: > Isn't CoffeeScript just a compiler to convert a cleaner syntax into > Javascript? If so, why would you need such a thing for Python, where > the syntax is already clean and simple? :-) Coffeescript is a more functional syntax. On that note, Python isn't as functional as it could be. e.g. the "Python Coffeescript" could add pattern matching or TCO or something. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: copy on write
On Thu, Feb 2, 2012 at 11:28 AM, MRAB wrote: > Should failed assignment be raising TypeError? Is it really a type > error? A failed setitem should be a TypeError as much as a failed getitem should. Should 1[0] be a TypeError? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Common LISP-style closures with Python
On Sat, Feb 4, 2012 at 5:58 AM, Arnaud Delobelle wrote: > I think what Chris asking is: what is the feature of Common-Lisp > closures that Python closures share but other languages don't? > > I think what he is implying is that there is no such feature. Python > closures are no more "Common-Lisp-style" than they are "Scheme-style" > or "Smalltalk-like" or any other language-like. "No such feature"? What's that nonlocal thing then? The above function could not be written that way in Python 2. Of course maybe we want to put this feature in another category, but anyway, the function couldn't be written in some languages, even though they have closures. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: what is the difference between @property and method
On Thu, Feb 9, 2012 at 3:50 AM, Zheng Li wrote: > class A(object): >@properymethod >def value1(self): > return 'value1' > >def value2(self): >return 'value2' > > what is the difference between value1 and value2. There is no such thing as @properymethod After you change the code to use @property, try writing it in the interactive interpreter and calling A().value2(). Then try calling A().value1() . Or maybe try googling for it. The fourth result for "property python" for me is http://adam.gomaa.us/blog/2008/aug/11/the-python-property-builtin/ -- It is kind of funny that the docs don't ever explicitly say what a property is. http://docs.python.org/library/functions.html#property -- Devin -- http://mail.python.org/mailman/listinfo/python-list
re module: Nothing to repeat, but no sre_constants.error: nothing to repeat ?
Hey Pythonistas, Consider the regular expression "$*". Compilation fails with the exception, "sre_constants.error: nothing to repeat". Consider the regular expression "(?=$)*". As far as I know it is equivalent. It does not fail to compile. Why the inconsistency? What's going on here? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: Entitlements [was Re: Python usage numbers]
On Tue, Feb 14, 2012 at 6:31 AM, Duncan Booth wrote: > Here's a clue: No flu viruses are treatable with antibiotics. Oh my god we're too late! Now they're ALL resistant! -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: re module: Nothing to repeat, but no sre_constants.error: nothing to repeat ?
On Tue, Feb 14, 2012 at 8:20 AM, Vinay Sajip wrote: > $ is a meta character for regular expressions. Use '\$*', which does > compile. I mean for it to be a meta-character. I'm wondering why it's OK for to repeat a zero-width match if it is a zero-width assertion. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: re module: Nothing to repeat, but no sre_constants.error: nothing to repeat ?
On Tue, Feb 14, 2012 at 10:05 AM, Vlastimil Brom wrote: > However, is there any realistic usecase for repeated zero-width anchors? Maybe. There is a repeated zero-width anchor is used in the Python re test suite, which is what made me notice this. I assume that came from some actual use-case. (see: http://hg.python.org/cpython/file/096e856a01aa/Lib/test/test_re.py#l599 ) And yeah, even something as crazy as ()* works, but as soon as it becomes (a*)* it doesn't work. Weird. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: re module: Nothing to repeat, but no sre_constants.error: nothing to repeat ?
On Tue, Feb 14, 2012 at 1:05 PM, MRAB wrote: >> And yeah, even something as crazy as ()* works, but as soon as it >> becomes (a*)* it doesn't work. Weird. >> > I think it's a combination of warning the user about something that's > pointless, > as in the case of "$*", and producing a pattern which could cause the > internal > regex engine to get stuck in an infinite loop. Considering that ()* works fine, I can't imagine it ever gets stuck in infinite loops. But I admit I am too lazy to check against the interpreter. Also, complete failure is an exceptionally (heh) poor way of warning people about stuff. I hope that's not really it. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: re module: Nothing to repeat, but no sre_constants.error: nothing to repeat ?
On Tue, Feb 14, 2012 at 9:08 PM, MRAB wrote: > There is one place in the re engine where it tries to avoid getting > stuck in an infinite loop because of a zero-width match, but the fix > inadvertently causes another bug. It's described in issue #1647489. Just read the issue. Interesting, didn't know that was a bug rather than deliberate behavior. The other behavior (only match empty space once) makes more sense though. Thanks for linking. Still, that's for avoiding infinite loops in finditer/findall, not match/search :S -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit.register in case of errors
On Wed, Feb 15, 2012 at 8:33 AM, Mel Wilson wrote:
> The usual way to do what you're asking is
>
> if __name__ == '__main__':
> main()
> goodbye()
>
> and write main so that it returns after it's done all the things it's
> supposed to do. If you've sprinkled `sys.exit()` all over your code, then
> don't do that. If you're forced to deal with a library that hides
> `sys.exit()` calls in the functions, then you have my sympathy. Library
> authors should not do that, and there have been threads on c.l.p explaining
> why they shouldn't.
In such a case. one can do::
if __name__ == '__main__':
try:
main()
except SystemExit:
pass
goodbye()
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Language missing maximum constant of numeric types!
On Fri, Feb 24, 2012 at 9:25 AM, Neil Cerutti wrote:
> The only time I've naively pined for such a thing is when
> misapplying C idioms for finding a minimum value.
>
> Python provides an excellent min implementation to use instead.
min can be a little inconvenient. As soon as anything complicated has
to be done during the min expression, you need to switch to using
something else for sanity's sake. In that vein, I do actually
sometimes use float('inf') (for numbers), or a custom max/min object.
Silly and completely nonserious addendum:
Forgive me, I have spoken in error! min is the one true way, for you
can still do it with a little wrangling, as follows:
@operator.itemgetter(1)
@min
@apply
def closest_object():
for x in xrange(board_width)
for y in xrange(board_height):
try:
entity = board.get_entity(x, y)
except EntityNotFound:
pass
else:
yield distance(player.pos, entity.pos), entity
Please don't kill me.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python math is off by .000000000000045
On Sat, Feb 25, 2012 at 2:08 PM, Tim Wintle wrote: > > It seems to me that there are a great many real numbers that can be > > represented exactly by floating point numbers. The number 1 is an > > example. > > > > I suppose that if you divide that count by the infinite count of all > > real numbers, you could argue that the result is 0%. > > It's not just an argument - it's mathematically correct. ^ this The floating point numbers are a finite set. Any infinite set, even the rationals, is too big to have "many" floats relative to the whole, as in the percentage sense. In fact, any number we can reasonably deal with must have some finite representation, even if the decimal expansion has an infinite number of digits. We can work with pi, for example, because there are algorithms that can enumerate all the digits up to some precision. But we can't really work with a number for which no algorithm can enumerate the digits, and for which there are infinitely many digits. Most (in some sense involving infinities, which is to say, one that is not really intuitive) of the real numbers cannot in any way or form be represented in a finite amount of space, so most of them can't be worked on by computers. They only exist in any sense because it's convenient to pretend they exist for mathematical purposes, not for computational purposes. What this boils down to is to say that, basically by definition, the set of numbers representable in some finite number of binary digits is countable (just count up in binary value). But the whole of the real numbers are uncountable. The hard part is then accepting that some countable thing is 0% of an uncountable superset. I don't really know of any "proof" of that latter thing, it's something I've accepted axiomatically and then worked out backwards from there. But surely it's obvious, somehow, that the set of finite strings is tiny compared to the set of infinite strings? If we look at binary strings, representing numbers, the reals could be encoded as the union of the two, and by far most of them would be infinite. Anyway, all that aside, the real numbers are kind of dumb. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
On Wed, Feb 29, 2012 at 6:43 AM, Chiron wrote: > Personally, I think this whole issue of precedence in a programming > language is over-rated. It seems to me that grouping of any non-trivial > set of calculations should be done so as to remove any possible confusion > as to intent. Some languages do this. e.g. all lisps. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots Af
On Thu, Mar 1, 2012 at 12:07 AM, Chiron wrote: > On Wed, 29 Feb 2012 23:10:48 -0500, Shmuel (Seymour J.) Metz wrote: > >> ROTF,LMAO! You obviously don't have a clue as to what Mathematics means. >> Free hint: it doesn't mean Arithmetic. You're as bigoted as Xah Lee, > > > Hmm... maybe, instead of just ridiculing him, you could explain where he > is mistaken. Of course, doing that is a *LOT* harder than just calling > him a bigot. I agree. Perhaps this is a good primer: http://www.maa.org/devlin/LockhartsLament.pdf -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: The original command python line
On Sun, Mar 4, 2012 at 1:20 AM, Damjan Georgievski wrote: > How come? > I'm using explicit relative imports, I thought they were the new thing? Explicit relative imports are fine. Implicit relative imports can create multiple module objects for the same source file, which breaks things like exception handling (because exception types are unequal if they're from different classes, even if the different classes come from two executions of the same source code). -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting Python to an embedded system
On Sun, Mar 4, 2012 at 5:58 AM, Justin Drake wrote: > I am working with an ARM Cortex M3 on which I need to port Python > (without operating system). What would be my best approach? I just > need the core Python and basic I/O. How much time are you willing to budget to this? Porting something to bare metal is not a small task. It's probably only worth it if you're doing it for academic purposes. I expect for anything real-world it'd be faster to do whatever it is you want to do using something that already runs on the bare metal. (e.g. http://armpit.sourceforge.net/ for Scheme). There used to be Flux OSKit ( http://www.cs.utah.edu/flux/oskit/ ) for porting languages to bare metal, but it doesn't support ARM and it's been dead a while. If you're really set on this, I'd try to see if there's something similar out there, somewhere. 'cause writing an OS from scratch would suck. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Wed, Mar 14, 2012 at 8:27 PM, Chris Angelico wrote: > On Thu, Mar 15, 2012 at 10:54 AM, Arnaud Delobelle wrote: >> I don't know this book and there may be a pedagogical reason for the >> implementation you quote, but pairwise_sum is probably better >> implemented in Python 3.X as: >> >> def pairwise_sum(list1, list2): >> return [x1 + x2 for x1, x2 in zip(list1, list2)] > > Okay, here's something for debate. > > Should the readability of a language be gauged on the basis of its > standard library, or should you be comparing actual code? "Actual code" often uses the standard library. > For instance, a quine in C can be fairly complex and messy, and it can > be unobvious what it's doing - but in HQ9+ it's easy. Is it fair to > compare on that basis, or should you actually implement the same / > equivalent code in each before judging? It's fair. But it's also fair to note that the comparison is silly, because the easiness of writing quines doesn't correspond with the easiness of doing productive things. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: cmd2, an extenstion of cmd that parses its argument line
There already is a module named cmd2: http://pypi.python.org/pypi/cmd2 -- Devin On Mon, Mar 19, 2012 at 1:11 AM, wrote: > Dear all, > > I would like to announce the first public release of cmd2, an extension of > the standard library's cmd with argument parsing, here: > https://github.com/anntzer/cmd2. > > Cmd2 is an extension built around the excellent cmd module of the standard > library. Cmd allows one to build simple custom shells using ``do_*`` > methods, > taking care in particular of the REPL loop and the interactive help. > However, > no facility is given for parsing the argument line (do_* methods are > passed the > rest of the line as a single string argument). > > With Cmd2, ``do_*`` methods are type-annotated, either using Python 3's > function annotation syntax, or with an ad-hoc ``annotate`` decorator, > allowing > the dispatcher to parse the argument list for them. > > Antony Lee > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation, assignment in expression.
On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm wrote: > On 3/25/2012 15:48, Tim Chase wrote: >> >> The old curmudgeon in me likes the Pascal method of using "=" for >> equality-testing, and ":=" for assignment which feels a little closer to >> mathematical use of "=". > > > Unfortunately, ":=" means "is defined as" in mathematics. The "right" > operator would have been "<-". "Is defined as" is actually pretty reasonable. "Define this to be that" is a common way to speak about assignment. Its only difference is the present tense. For example, in Python, "def" stands for "define", but we can overwrite previous definitions:: def f(x): return x def f(x): return 2 f(3) == 2 In fact, in pretty every programming language that I know of with a "define" assignment verb, this is so. For example, in Scheme, x is 2 at the end:: (define x 1) (define x 2) x -- Devin -- http://mail.python.org/mailman/listinfo/python-list
