I've been playing with recursion, it's very satisfying.
However, it appears that even if I sys.setrecursionlimit(10), it blows
up at about 24,000 (appears to reset IDLE). I guess there must be a lot of
overhead with recursion, if only 24k times are killing my memory?
I'm playing with a challe
On Wed, Jan 8, 2014 at 3:30 PM, Oscar Benjamin
wrote:
> The garbage collector has nothing to do with the memory usage of immutable
> types like ints. There are deallocated instantly when the last reference
> you hold is cleared (in CPython). So if you run out of memory because of
> them then it is
On Wed, Jan 8, 2014 at 3:42 PM, Emile van Sebille wrote:
>
> Without seeing your code it's hard to be specific, but it's obvious you'll
> need to rethink your approach. :)
Yes, it's clear I need to do the bulk of it without recusion, I haven't
really thought about how to do that. I may or may
On Wed, Jan 8, 2014 at 4:23 PM, eryksun wrote:
> You can create a worker thread with a larger stack using the threading
> module. On Windows the upper limit is 256 MiB, so give this a try:
>
quite excellent, mwahaha... another shovel to help me excavate out the
bottom of my hole... I'll play wi
On Wed, Jan 8, 2014 at 5:15 PM, spir wrote:
> Funny and useful exercise in recursion: write a func that builds str and
> repr expressions of any object, whatever its attributes, inductively. Eg
> with
>
Hmm, can't say I get the joke. I haven't really played with repr, though I
think I understand
On Wed, Jan 8, 2014 at 6:16 PM, Dave Angel wrote:
> I can't see the bodies of any of your messages (are you perchance posting
> in html? ), but I think there's a good chance you're abusing recursion and
> therefore hitting the limit much sooner than necessary. I've seen some code
> samples here
On Thu, Jan 9, 2014 at 12:27 AM, eryksun wrote:
> The old float freelist was the same design as the one for 2.x int
> (PyInt, not PyLong), which grows without bound. The design also
> allocates objects in 1 KiB blocks (approx. size). glibc's malloc will
> use the heap for a block that's this smal
On Thu, Jan 9, 2014 at 5:41 AM, Steven D'Aprano wrote:
>
> Keith, if you are able, and would be so kind, you'll help solve this
> issue for Dave if you configure your mail client to turn so-called "rich
> text" or formatted text off, at least for this mailing list.
Well, hopefully this is plain t
Amy, you may want to get a little clearer on the difference between
defining a function, and calling one. The definition is sort of a
generic process, it's when you are calling it that you really fill in
the blanks, and the function does what it's designed for (whether you
like it or not!).
You mi
Amy, be aware that there are slightly different versions of Python
floating around, and the example Dayo gave you uses a slightly
different print statement (no parens) than the example you provided
(which probably indicates that your Python requires them).
Good luck, you're on your way!
Keith
___
Amy, judging from Danny's replies, you may be emailing him and not the
list. If you want others to help, or to report on your progress,
you'll need to make sure the tutor email is in your reply to:
Often, people prefer you to respond to the list, if there isn't
something particularly personal in y
On Sat, Jan 11, 2014 at 7:37 PM, Alan Gauld wrote:
> In other words, think about the design of your code don't
> just type randomly.
I prefer the "million monkeys at a million typewriters" approach to
coding... But then, it's all I've tried...
--
Keith
___
I've got this line:
for k in range(len(tcombo)):
tcombo_ep.append(list(combinations(tcombo, k+1)))
generating every possible length combination of tcombo. I then test
them, and throw most of them away. I need to do this differently, it
gets way too big (crashes my computer).
I'm going to pla
On Sun, Jan 12, 2014 at 4:19 AM, Alan Gauld wrote:
> lambdas are just a shortcut for single expression functions.
> You never need them, they just tidy up the code a bit by
> avoiding lots of use-once short functions.
Thanks, I figured out how to iterate the combinations function. I'll
play with
every time I run it...
I'm generating a LOT of combinations.
On Sun, Jan 12, 2014 at 9:33 AM, Dave Angel wrote:
> Keith Winston Wrote in message:
>> I've got this line:
>>
>> for k in range(len(tcombo)):
>> tcombo_ep.append(list(combinations(tcombo, k+1
On Sun, Jan 12, 2014 at 7:44 AM, Alan Gauld wrote:
> OK< So there is nothing here about the orders being the same.
> That makes it much easier.
There's another approach, I think, that's quite easy if order IS important.
Iterate through the letters of product, find() them initially from the
begi
OOps, I never used the "success" boolean in my code, but forgot to
remove it. Sorry.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
On Sun, Jan 12, 2014 at 2:22 PM, Keith Winston wrote:
> if test:
Sigh and this line needs to read (if it's going to do what I said):
if test != -1:
--
Keith
___
Tutor maillist - Tutor@python.org
To unsubscribe o
On Sun, Jan 12, 2014 at 2:38 PM, Keith Winston wrote:
> Sigh and this line needs to read (if it's going to do what I said):
As Alan pointed out, the examples provided do NOT account for order,
so if one uses my (corrected) algorithm, you get different results
from the examples. Wit
On Sun, Jan 12, 2014 at 2:22 PM, Keith Winston wrote:
> There's another approach, I think, that's quite easy if order IS important.
Alas, there's one further problem with my script, relating to testing
multiple sequential letters in product... but I'm not going to say
m
I'm working through some of the Project Euler problems, and the
following might spoil one of the problems, so perhaps you don't want
to read further...
The problem relates to finding all possible combinations of coins that
equal a given total. I'm basically brute-forcing it, which is probably
not
Thanks everyone, things to chew on. I'll look at the other itertools
functions mentioned. I did solve Proj. Euler 15 & 18 (and it's
corresponding 67), one more elegantly than the other, and I have given
some thought to how to break this one down, but haven't figured it out
yet. I think I might not
Danny, thanks for that exposition. I don't have time to absorb it
yet,though I will attempt to soon, but I wanted to thank you for your
effort in the meantime.
Keith
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
h
On Mon, Jan 13, 2014 at 1:14 AM, Roelof Wobben wrote:
> I have read all comments and im a little bit confused.
> About which script are we talkimng about. I have seen a lot.
I am talking about the script/approach I posted. Others have posted
other scripts. Hopefully you have the capacity, with w
Ah, I got through it. Yes, I started down this path, but didn't dot
the i's. Thanks. I'm going to do some more reading on dynamic
programming...
Keith
On Mon, Jan 13, 2014 at 12:51 PM, Keith Winston wrote:
> Danny, thanks for that exposition. I don't have time to absorb
Yikes, Peter, that's scary. Wow.
On Mon, Jan 13, 2014 at 1:22 PM, Peter Otten <__pete...@web.de> wrote:
> Peter Otten wrote:
>
>> Emile van Sebille wrote:
>>
>>> On 01/12/2014 12:21 PM, Peter Otten wrote:
>>>
>>> test("axbxc", "abc")
True
>>> test("abbxc", "abc")
False
s*** just got real.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
On Wed, Jan 15, 2014 at 6:12 AM, Steven D'Aprano wrote:
> You're selling youself short. From what I've seen of you on this list,
> you might be a beginner, but you've got the right sort of inquiring mind
> to go far as a programmer.
Thanks Steven, I've abruptly gotten clear how much work I have a
On Thu, Jan 16, 2014 at 5:44 AM, spir wrote:
> This, in addition to the requirement of uniqueness which as you say is
> probably best met using a set (after filter). This may lead to you chosing
> to store, even if otherwise not truely necessary. An question is: what kind
> of data are combination
I don't really get iterators. I saw an interesting example on
Stackoverflow, something like
with open('workfile', 'r') as f:
for a, b, c in zip(f, f, f):
And this iterated through a, b, c assigned to 3 consecutive lines of
the file as it iterates through the file. I can sort of pretend t
On Sat, Jan 18, 2014 at 4:22 AM, Chris “Kwpolska” Warrick
wrote:
> Here is a poor man’s pure-python re-implementation of `for`:
> https://gist.github.com/Kwpolska/8488091
This will be very handy the next time I run out of for's, or have a
surplus of while's. Fairly common.
Seriously though, than
On Sat, Jan 18, 2014 at 2:19 PM, eryksun wrote:
> `xrange` and 3.x `range` aren't iterators. They're sequences. A
> sequence implements `__len__` and `__getitem__`, which can be used to
> implement an iterator, reversed iterator, and the `in` operator (i.e.
> `__contains__`).
I'm so glad you said
Well, as usual thanks for all this, it's really great. I'd worked out
that it was a distinction between iterators and iterables, though I'm
going to Oscar's description a few more times: most of it made sense,
but there are subtleties.
For example, this from the Python 3.3 tutorial:
We say such a
On Sun, Jan 19, 2014 at 2:02 PM, Oscar Benjamin
wrote:
> I think that's just an editing mistake. If you replace the word "iterator"
> with "construct" then it makes sense: We have seen that the for statement is
> such a construct.
Fair enough. Thanks. But I think that it underlines the ease with
On Sun, Jan 19, 2014 at 11:55 AM, Alan Gauld wrote:
> It has reached the point that I'm back to looking for a new teaching
> language. In Python 3 the decision has clearly been made to focus on
> supporting Python's role as a professional software engineering language
> at the expense of being a s
On Sun, Jan 19, 2014 at 11:33 AM, Alan Gauld wrote:
help(''.find)
> Help on built-in function find:
Erm, getting what you want from help can be work.
Help(find) # doesn't work at all.
What Alan did above was create an empty string, by using two single
quotes next to each other ('', not t
On Sun, Jan 19, 2014 at 3:50 PM, Alan Gauld wrote:
>> How would Python know whether you want find for gettext, mmap, str,
>> xml.etree.ElementTree.Element or xml.etree.ElementTree.ElementTree?
>
>
> Absolutely, but a newbie doesn't even guess that more than one find would
> exist. Or even that the
If you are playing around at the Python prompt (the >>>), which you
really should be to get the hang of this stuff, you might notice that
the bracket indexing that you and everyone is talking about works both
on strings (Y) and on lists (X: in this case, a list of strings). They
may not behave the
On Wed, Jan 22, 2014 at 6:40 AM, Alan Gauld wrote:
>> else:
>>return ' '
>
>
> Notice that this return will throw you out of the function so
> you don't process any more strings. You might like to look
> at 'continue' as an alternative.
You actually don't need to do anything with thi
I'm working my way through some of the examples in
http://ivory.idyll.org/articles/advanced-swc/#list-comprehensions
And tried this one:
>>> class MyTrickyIter:
... def __init__(self, thelist):
... self.thelist = thelist
... self.index = -1
...
... def __iter__(self):
... retu
On Thu, Jan 23, 2014 at 12:21 AM, Devin Jeanpierre
wrote:
> in Python 3, it should be __next__, not next.
Ah! That's it! Thanks!!!
> I'd suggest staying away from any old blog posts and articles, unless
> you'd care to learn Python 2.x instead of 3.x. ;)
Yeah, but this is a REALLY GOOD resource
On Thu, Jan 23, 2014 at 5:56 AM, spir wrote:
> Yes, but that way others learn as well :-) And many people prefere learning
> via human interaction then dealing with arid texts
Well, you caught me. I do run out of steam just plowing through
lessons & such: it really helps to have actual humans to
On Thu, Jan 23, 2014 at 3:09 AM, Peter Otten <__pete...@web.de> wrote:
> But why not install Python 2.7 on your machine, too? That would allow you
> run the examples as is.
Y'know, it's funny, but I have 2.7 installed. But since I was almost
certain it was a 2to3 kind of problem, I wanted to figur
On Thu, Jan 23, 2014 at 7:05 AM, eryksun wrote:
> Generally you'll make `__iter__` a generator, so you don't have to
> worry about implementing `__next__`. Also, the built-in function
> `next` was added in 2.6, so you don't have to worry about the method
> name difference between 2.x and 3.x, eith
On Thu, Jan 23, 2014 at 1:36 PM, Devin Jeanpierre
wrote:
> Again, nothing was incorrect about the example. Every iterator has
> this "problem".
Hmmm. Well, here's what he actually said about that example, since I
don't think I've explained correctly:
*
With iterators, one thing to watch out
On Thu, Jan 23, 2014 at 7:05 AM, eryksun wrote:
> Generally you'll make `__iter__` a generator, so you don't have to
> worry about implementing `__next__`. Also, the built-in function
> `next` was added in 2.6, so you don't have to worry about the method
> name difference between 2.x and 3.x, eith
The file would appear to not be on your search path, that is, in any
directory in which Python is expecting to find it. Either move it to a
directory on your path, or change your path to include it's location.
The easiest way to find out what your path is, that I know, is
import sys
sys.path
Good
I should have mentioned, the other possibility is that the file does
not, in fact, exist, but I assume you put it out there somewhere?
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/l
On Fri, Jan 24, 2014 at 4:50 AM, Steven D'Aprano wrote:
> Python does not use a search path for the open() function, only for
> imports. With open(), it uses a simple rule:
>
> - absolute paths will look only in that exact location;
>
> - relative paths are always relative to the current working d
On Sat, Jan 25, 2014 at 3:57 AM, spir wrote:
>> .009 to the price, so that people do not have to type the full amount.
>> Example, 3.49 /gallon would return 3.499 /gallon.
>>
>> This is what I have tried and the results of it.
>>
>> def gas_price(price):
>> price == raw_input("What is the pr
On Sat, Jan 25, 2014 at 3:57 AM, spir wrote:
> Note: AFAIK most financial software use integers for this reason and to
> avoid (or control) rounding errors.
I don't think this is true (no flame intended, hopefully you know I'm
forever in your debt Denis): there's a famous scam where insiders at a
Also, just to be clear: I'd suggest floats because decimal requires
importing a module and using the non-built-in features thereof,
especially if you're going to do something like
decimal.getcontext().prec (even that doesn't set precision AFTER the
decimal point... only total precision). My point b
On Sat, Jan 25, 2014 at 5:09 PM, Oscar Benjamin
wrote:
> Perhaps it would be better though to point at this:
round(D('0.123456'), 3)
> Decimal('0.123')
I think you are right. I didn't even think of round(). I think we have
confounded two issues in this thread, the internal
representation/acc
On Wed, Jan 29, 2014 at 12:11 PM, Mark Lawrence wrote:
> I think it's worth pointing out that there is a difference here between the
> OP's 'Site Name's Harbor.JPG' and Peter's "Site Name's Harbor.JPG". Left as
> homework for the newbies :)
I'll bite. But are you just referring to the tuple iss
On Wed, Jan 29, 2014 at 3:03 PM, Mark Lawrence wrote:
> Nothing to do with tuples. Tools such as syntax checkers or MkI eyeballs
> come in useful here. Although such tools probably won't pick up the
> incorrect spelling of "harboUr" :)
Alas, now I'm more confused. I don't see any mispellings in
101 - 155 of 155 matches
Mail list logo
