Re: [Tutor] Mailing list archive oddity?
> So I wanted to reference a post I had already deleted and I looked at the > archive (http://mail.python.org/pipermail/tutor/). > > My question...how do I get a future capable email client like the archive? :) What mail client do you use? Does it offer a way to move posts out of the inbox, without deleting them? That's what I do, but I use gmail. Devin On Thu, Sep 29, 2011 at 3:55 PM, Prasad, Ramit wrote: > So I wanted to reference a post I had already deleted and I looked at the > archive (http://mail.python.org/pipermail/tutor/). > > My question...how do I get a future capable email client like the archive? :) > > Ramit > > > Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology > 712 Main Street | Houston, TX 77002 > work phone: 713 - 216 - 5423 > > > > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of > securities, accuracy and completeness of information, viruses, > confidentiality, legal privilege, and legal entity disclaimers, > available at http://www.jpmorgan.com/pages/disclosures/email. > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Mailing list archive oddity?
> I think you misunderstood my question. The web archive of the list has a few > entries that have not occurred yet (which you may have noticed if you visited > the link). Ah. I have an unfortunate medical condition where I only click hyperlinks when they don't matter. Devin On Thu, Sep 29, 2011 at 4:25 PM, Prasad, Ramit wrote: > -Original Message----- > From: Devin Jeanpierre [mailto:jeanpierr...@gmail.com] > Sent: Thursday, September 29, 2011 3:11 PM > To: Prasad, Ramit > Cc: tutor@python.org > Subject: Re: [Tutor] Mailing list archive oddity? > >> So I wanted to reference a post I had already deleted and I looked at the >> archive (http://mail.python.org/pipermail/tutor/). >> >> My question...how do I get a future capable email client like the archive? :) > > What mail client do you use? Does it offer a way to move posts out of > the inbox, without deleting them? > > That's what I do, but I use gmail. > > Devin > > -- > > I think you misunderstood my question. The web archive of the list has a few > entries that have not occurred yet (which you may have noticed if you visited > the link). > > January 2027: [ Thread ] [ Subject ] [ Author ] [ Date ] [ Gzip'd Text > 597 bytes ] > November 2012: [ Thread ] [ Subject ] [ Author ] [ Date ] [ Gzip'd Text > 2 KB ] > > I was asking (facetiously) if there was an email client that could receive > email from the future. I am curious to how this happened, but I am not sure > anyone on this list is a list administrator and would know. > > Ramit > > > Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology > 712 Main Street | Houston, TX 77002 > work phone: 713 - 216 - 5423 > > > > > This email is confidential and subject to important disclaimers and > conditions including on offers for the purchase or sale of > securities, accuracy and completeness of information, viruses, > confidentiality, legal privilege, and legal entity disclaimers, > available at http://www.jpmorgan.com/pages/disclosures/email. > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] how to unique the string
You should be able to do this yourself, with the help of the following link: http://docs.python.org/library/stdtypes.html#set Is this a homework question? Devin On Sat, Oct 22, 2011 at 12:09 PM, lina wrote: > Hi, > > I googled for a while, but failed to find the perfect answer, > > for a string > > ['85CUR', '85CUR'] > > how can I unique it as: > > ['85CUR'] > > Thanks, > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which should it be, lists, tuples, dictionary or files?
> Another option for you would be a shelve.(See the shelve module > in the standard library) A file that acts like a dictionary. > You can store a list of values against a single key. It's probably worth mentioning that shelve is not secure; loading a saved shelf can involve executing arbitrary python code embedded inside it. This probably isn't important for this particular project, but maybe in the future, if you consider using shelf for something more security-conscious... -- Devin On Mon, Jan 2, 2012 at 8:24 PM, Alan Gauld wrote: > On 03/01/12 00:31, Ken G. wrote: > >>> If you to store the data permanently, it has to go into a file. I >>> suggest you learn about INI files to start with. Start by googling for >> >> Okay, thanks. I will look into it. Have not heard of INI file format. > > > It's a Microsoft text file format invented for use on Windows but > in fact is applicable to any kind of data stoorage with one or > two levels of key. > > Another option for you would be a shelve.(See the shelve module > in the standard library) A file that acts like a dictionary. > You can store a list of values against a single key. > > Alternatively a simple SqlLite database would give you general searchability > if that is important. > > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > > > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Your thoughts on designing python code for unit testing?
I've found that bottom-up development favors testable code. That is, rather than thinking of the problem to be solved, thinking in terms of the tools (functions) one would use to solve the problem. These tools can be written to be testable, and then it all builds up in this tower of easily-testable and easy-to-use things until you have to actually solve the problem at hand, at which point, ideally, it's just the boring work of writing down the problem in terms of these tools. (Digression: languages that let you do this earn the well-earned reputation that source code can be like pseudocode). It also makes the functions smaller and easier to read, which is a nice bonus, especially during test failures -- lots of functions mean your tests can be granular and say exactly where the problem is (more or less), whereas being easy to read means less time searching for the mistake. -- Devin On Wed, Jan 4, 2012 at 10:48 PM, brian arb wrote: > > What are some of the strategies for designing code to be unit tested? > > > > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Subclassing Exceptions
> Inheriting from SyntaxError doesn't work! When I create a new exception, I > generally subclass from the built-in exception it most resembles, in case > there was some reason to also catch it via an ancestor. But I'm not sure if > that is really all that useful an idea in practice. How do you folk do it? If somebody wanted to catch a ValueError, would they also mean to catch my error? (The same with SyntaxError and so on). Probably not. If they would, then I raise the relevant exception. It is very possible to accidentally catch the wrong thing if you put too much in a try block, and I don't like making that any easier. -- Devin On Fri, Jan 6, 2012 at 10:24 PM, Chris Fuller wrote: > I had an interesting experience today. > > Python 2.7.1 (r271:86832, Nov 28 2010, 19:31:37) > [GCC 4.4.5] on linux2 > Type "help", "copyright", "credits" or "license" for more information. class Foo(Exception): > ... def __init__(self, a,b,c): > ... self.args = (a,b,c) > ... raise Foo(1,2,3) > Traceback (most recent call last): > File "", line 1, in > __main__.Foo: (1, 2, 3) class Foo(SyntaxError): > ... def __init__(self, a,b,c): > ... self.args = (a,b,c) > ... raise Foo(1,2,3) > Traceback (most recent call last): > File "", line 1, in > __main__.Foo: None > > > Inheriting from SyntaxError doesn't work! When I create a new exception, I > generally subclass from the built-in exception it most resembles, in case > there was some reason to also catch it via an ancestor. But I'm not sure if > that is really all that useful an idea in practice. How do you folk do it? > > By the way, inheriting from StandardError, the direct ancestor of > SyntaxError, works as expected, and its parent is Exception. > > Cheers > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] making a custom file parser?
> Parsing XML with regular expressions is generally very bad idea. In > the general case, it's actually impossible. XML is not what is called > a regular language, and therefore cannot be parsed with regular > expressions. You can use regular expressions to grab a limited amount > of data from a limited set of XML files, but this is dangerous, hard, > and error-prone. Python regexes aren't regular, and this isn't XML. A working XML parser has been written using .NET regexes (sorry, no citation -- can't find it), and they only have one extra feature (recursion, of course). And it was dreadfully ugly and nasty and probably terrible to maintain -- that's the real cost of regexes. In particular, his data actually does look regular. > I'll assume that said "(.*)". There's still a few problems: < and > > shouldn't be escaped, which is why you're not getting any matches. > Also you shouldn't use * because it is greedy, matching as much as > possible. So it would match everything in between the first and > the last tag in the file, including other tags > that might show up. On the "can you do work with this with regexes" angle: if units can be nested, then neither greedy nor non-greedy matching will work. That's a particular case where regular expressions can't work for your data. > Test it carefully, ditch elementtree, use as little regexes as > possible (string functions are your friends! startswith, split, strip, > et cetera) and you might end up with something that is only slightly > ugly and mostly works. That said, I'd still advise against it. turning > the files into valid XML and then using whatever XML parser you fancy > will probably be easier. He'd probably do that using regexes. Easiest way is probably to write a real parser using some PEG or CFG thingy. Less error-prone. Overall agree with advice, though. Just being picky. Sorry. -- Devin On Sat, Jan 7, 2012 at 3:15 PM, Hugo Arts wrote: > On Sat, Jan 7, 2012 at 8:22 PM, Alex Hall wrote: >> I had planned to parse myself, but am not sure how to go about it. I >> assume regular expressions, but I couldn't even find the amount of >> units in the file by using: >> unitReg=re.compile(r"\(*)\") >> unitCount=unitReg.search(fileContents) >> print "number of units: "+unitCount.len(groups()) >> >> I just get an exception that "None type object has no attribute >> groups", meaning that the search was unsuccessful. What I was hoping >> to do was to grab everything between the opening and closing unit >> tags, then read it one at a time and parse further. There is a tag >> inside a unit tag called AttackTable which also terminates, so I would >> need to pull that out and work with it separately. I probably just >> have misunderstood how regular expressions and groups work... >> > > Parsing XML with regular expressions is generally very bad idea. In > the general case, it's actually impossible. XML is not what is called > a regular language, and therefore cannot be parsed with regular > expressions. You can use regular expressions to grab a limited amount > of data from a limited set of XML files, but this is dangerous, hard, > and error-prone. > > As long as you realize this, though, you could possibly give it a shot > (here be dragons, you have been warned). > >> unitReg=re.compile(r"\(*)\") > > This is probably not what you actually did, because it fails with a > different error: > a = re.compile(r"\(*)\") > Traceback (most recent call last): > File "", line 1, in > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.py", > line 188, in compile > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.py", > line 243, in _compile > sre_constants.error: nothing to repeat > > I'll assume that said "(.*)". There's still a few problems: < and > > shouldn't be escaped, which is why you're not getting any matches. > Also you shouldn't use * because it is greedy, matching as much as > possible. So it would match everything in between the first and > the last tag in the file, including other tags > that might show up. What you want is more like this: > > unit_reg = re.compile(r"(.*?)") > > Test it carefully, ditch elementtree, use as little regexes as > possible (string functions are your friends! startswith, split, strip, > et cetera) and you might end up with something that is only slightly > ugly and mostly works. That said, I'd still advise against it. turning > the files into valid XML and then using whatever XML parser you fancy > will probably be easier. Adding quotes and closing tags and removing > comments with regexes is still bad, but easier than parsing the whole > thing with regexes. > > HTH, > Hugo > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org To unsubs
Re: [Tutor] making a custom file parser?
> IIRC, Python's only non-regular feature is backreferences though Probably. I'm not too familiar with a couple other features or how their semantics work, in particular the (?(id)yes|no) syntax. > I'm not calling bs or anything, I don't know anything about .net > regexes and I'll readily believe it can be done (I just want to see > the code for myself). They add the ability to push and pop from a stack, which turns their regular expressions into at-least-as-powerful as push-down automata, which are equivalent in power to context-free-grammars, which means they can match XML. I think this has been well-known in the .NET community for years, but nobody had ever done it, and nobody ever mentioned it. It's a dirty secret you don't tell the newbies because then they think regexps are fine to use for everything. It's also why I don't like the "this isn't regular so don't use regular expressions" spiel. We call things regular expressions even when they're context-free parsing expressions! The term has meaning, but it's no longer tied to finite state automata, and any argument along that lines is just waiting to be broken by the next feature addition to the re module. Anyway, I found the reference I was thinking of: http://porg.es/blog/so-it-turns-out-that-dot-nets-regex-are-more-powerful-than-i-originally-thought > Quite right. We haven't seen enough of it to be sure, but that little > bite seems parseable enough with some basic string methods and one or > two regexes. That's really all you need, and trying to do the whole > thing with pure regex is just needlessly overcomplicating things (I'm > pretty sure we all actually agree on that). Oh I dunno. If the regex would be simple, it'd be the simplest solution. As soon as you have order-independence though... > You mean like flex/bison? May be overkill, but then again, maybe not. > So much depends on the data. Flex/Bison are a little old-school / difficult to deal with. I'm more thinking LEPL or PyMeta or something. -- Devin On Sun, Jan 8, 2012 at 9:06 PM, Hugo Arts wrote: > On Mon, Jan 9, 2012 at 2:19 AM, Devin Jeanpierre > wrote: >>> Parsing XML with regular expressions is generally very bad idea. In >>> the general case, it's actually impossible. XML is not what is called >>> a regular language, and therefore cannot be parsed with regular >>> expressions. You can use regular expressions to grab a limited amount >>> of data from a limited set of XML files, but this is dangerous, hard, >>> and error-prone. >> >> Python regexes aren't regular, and this isn't XML. >> >> A working XML parser has been written using .NET regexes (sorry, no >> citation -- can't find it), and they only have one extra feature >> (recursion, of course). And it was dreadfully ugly and nasty and >> probably terrible to maintain -- that's the real cost of regexes. >> > > IIRC, Python's only non-regular feature is backreferences though; I'm > pretty sure that isn't enough to parse XML. It does not make it > powerful enough to parse context-free languages. I really would like > that citation though, tried googling for it but not much turned up. > I'm not calling bs or anything, I don't know anything about .net > regexes and I'll readily believe it can be done (I just want to see > the code for myself). But really I still wouldn't dare try without a > feature set like perl 6's regexes. And even then.. > > You're technically correct (it's the best kind), but I feel like it > doesn't really take away the general correctness of my advice ;) > >> In particular, his data actually does look regular. >> > > Quite right. We haven't seen enough of it to be sure, but that little > bite seems parseable enough with some basic string methods and one or > two regexes. That's really all you need, and trying to do the whole > thing with pure regex is just needlessly overcomplicating things (I'm > pretty sure we all actually agree on that). > >>> I'll assume that said "(.*)". There's still a few problems: < and > >>> shouldn't be escaped, which is why you're not getting any matches. >>> Also you shouldn't use * because it is greedy, matching as much as >>> possible. So it would match everything in between the first and >>> the last tag in the file, including other tags >>> that might show up. >> >> On the "can you do work with this with regexes" angle: if units can be >> nested, then neither greedy nor non-greedy matching will work. That's >> a particular case
Re: [Tutor] Error Checking/Defensive Programming
On Wed, Jan 25, 2012 at 10:36 PM, Michael Lewis wrote:
> Is it generally better to use try/except/else statements or if/elif/else?
> Or, is there a time and place for each?
There's a time and place for each. Most errors are indicated in the
form of an exception being raised, though.
> For a simple example, assume I want a user to enter a number
>
> 1) try:
> number = float(input('enter a number: ')
> except ValueError:
> print('enter a number.')
> else:
> print('you entered a number')
>
> OR
>
> 2) number = float(input('enter a number: ')
> if number >=0 or < 0:
> print('you entered a number')
> else:
> print('enter a number.')
>
float(x) doesn't return anything if the value it's passed can't be
converted to a float. The first way is the only way.
-- Devin
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Rounding Error
On Sat, Jan 28, 2012 at 1:20 AM, Steven D'Aprano wrote: > And finally, we come all the way back to the beginning again and say That's > not the right way to do it! Don't round the number *outside* of the string > formatting, get the string formatting to do it for you: Reason being because repr(round(0.1, 2)) != '0.1' (on older Pythons). String formatting does the right thing. Also don't use floats for currency, they can attract rounding errors and can't represent many common amounts with 100% precision, the way a Decimal or Fraction can (see decimal, fractions modules). For example, it can't represent 0.1 exactly, thus leading to the above situation. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Importing libraries
On Sat, Feb 4, 2012 at 6:35 AM, Steven D'Aprano wrote: > Michael Lewis wrote: >> >> Why don't I have to import str or list to access their attributes like I >> do >> with the math or random or any other library? > > > > Because they are built-in. That means they live inside the Python > compiler/interpreter itself. Blargh, lots of things are built in. The sys module is a built-in module, but you don't get access to it by default. It's because they're specially-chosen to be in the "builtin namespace". This is the namespace of things that are always accessible. This is different from being built into the interpreter -- hypothetically we could have something in the builtin namespace that is not part of Python itself. (You can do this by adding things to the builtin namespace by hand). -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] how to print a string in desired colour
On Sun, Feb 12, 2012 at 8:02 AM, Scott Nelson wrote: > On Sun, Feb 12, 2012 at 6:47 AM, Debashish Saha wrote: >> >> suppose i want to print 'hello world' in color blue.so what to do? >> > > There was a similar thread awhile ago. Unfortunately the answer isn't an > easy one. It depends on what operating system you use. Here's a link to > the old thread: http://comments.gmane.org/gmane.comp.python.tutor/67743 Colorama works on every major desktop platform. http://pypi.python.org/pypi/colorama -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] syntax error
On Sat, May 12, 2012 at 10:29 PM, bob gailer wrote: > oh - and always provide a specific meaningful subject My client has no idea what thread this post came from. Is it supposed to? -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Auto-response for your message to the "Tutor" mailing list
This is the third time I've received a message "for those of you new to the Tutor list". When does it stop? -- Devin On Sat, May 12, 2012 at 11:19 PM, wrote: > Your message for tutor@python.org, the Python programming tutor list, > has been received and is being delivered. This automated response is > sent to those of you new to the Tutor list, to point out a few > resources that can help with answering your own questions, or improve > the chances of getting a useful answer from the other subscribers. > > If your question is something akin to: > > "I've just heard about Python, and it sounds great! Where can I > find out more on how to program with Python?" > > or: > > "What's Python?" > > please read section 1 below. > > On the other hand, if your question is: > > "I've heard that Python is good for hacking -- I want to know > more!" > > or > > "Can you teach me how to break into a computer with Python?" > > please read section 2 at the bottom of this email. > > Section 1: -- > > The most comprehensive overview of python.org help resources is at > > http://www.python.org/Help.html > > The Python FAQ is available at > > http://www.python.org/doc/FAQ.html > > and it has answers to many questions that people ask, possibly > including your question. Another wealth of information and experience > can be found via the python.org searches, at > > http://www.python.org/search/ > > There you'll find comprehensive, easy-to-use searches over the > python.org web site and the Python newsgroup, comp.lang.python. > > Python has an online tutorial, available freely from > > http://www.python.org/doc/current/tutorial/index.html > > Finally, when you do send email to the Tutor list, be as clear as you > can about the problem, including, when relevant, details like: > > - Precise error messages, including complete tracebacks > - The hardware platform (available in the Python sys module as > sys.platform) > - The python version (sys.version) > - The python search path (sys.path) > > In general, be specific about what was going on connected with the > problem or what specific concept you're having difficulties with. The > better the info you provide, the more likely the helpers will be able > to glean the answer... > > There's a HOWTO that shows how to ask "smart" questions to technical > folks: > > http://catb.org/~esr/faqs/smart-questions.html > > Although it is provocative, it does have some good points, and is an > interesting read. > > > Note that no one is paid to read the tutor list or provide answers, > and most readers often have other work that demands their attention. > Well-posed requests for help are usually answered fairly promptly, but > occasionally a request slips by, so if you do not get a response with > one or two working days (it's usually quicker than that), please feel > free to send a followup, asking whether anyone is working on your > question. > > Anyway, your message is being delivered to the Tutor list as this one > is being sent. However, if your question was about as detailed as > "Teach me how to program in Python", do not count on an answer -- this > email contains all the information you need to start. Come back with > a more precise question, and we'll be glad to help. > > > Thanks! > > Section 2: -- > > We periodically get requests which ask about hacking or cracking or > breaking into computers. If you haven't yet, go read Eric Raymond's > article "How To Become a Hacker" at > http://catb.org/esr/faqs/hacker-howto.html > > If, after you've read that, you want help learning how to hack the way > Eric defines the word, then come back to us (and read Section 1 > above). If you want help learning how to crack, go look elsewhere -- > we're not interested in helping you do that. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] syntax error
On Sun, May 13, 2012 at 5:44 AM, Steven D'Aprano wrote: > Devin Jeanpierre wrote: >> >> On Sat, May 12, 2012 at 10:29 PM, bob gailer wrote: >>> >>> oh - and always provide a specific meaningful subject >> >> >> My client has no idea what thread this post came from. >> >> Is it supposed to? > > > > What's your client? I'm using Thunderbird, and it too doesn't have any idea. The gmail web interface. > I see that Bob's email does have an In-Reply-To header: > > In-Reply-To: > > > and if I look at the email which started this thread, Keitaro Kaoru's email > with no subject line, I see it has the same message ID: > > Message-ID: > > > > so my guess is that Thunderbird is just stupid. Welp. Not much I can do here. I should probably switch to a desktop client at some point. Thanks for the detective work. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] threading mind set
On Sun, May 13, 2012 at 8:31 PM, Steven D'Aprano wrote: >> Using processes and message passing, using dataflow, actors or CSP, >> parallelism and concurrency is far more straightforward. Not easy, >> agreed, but then programming isn't easy. > > My argument is that once you move beyond the one-operation-after-another > programming model, almost any parallel processing problem is harder than the > equivalent sequential version, inherently due to the parallelism. Except > perhaps for "embarrassingly parallel" problems, parallelism adds complexity > even if your framework abstracts away most of the tedious detail like > semaphores. If you agree that embarrassingly parallel multithreaded frameworks are easy, what do you think of dataflow programming? It is exactly the same, except that you can have multiple tasks, where one task depends on the output of a previous task. It shares the property that it makes no difference in what order things are executed (or sequential vs parallel), so long as the data dependencies are respected -- so it's another case where you don't actually have to think in a non-sequential manner. (Rather, think in a "vectorized" per-work-item manner.) http://en.wikipedia.org/wiki/Dataflow_programming It should be clear that not all ways of programming multithreaded code are equal, and some are easier than others. In particular, having mutable state shared between two concurrently-executing procedures is phenomenally hard, and when it's avoided things become simpler. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Teaching an 8-year-old programming.
I've heard remarkable things about http://www.programbydesign.org/ , but it's aimed at students a little older. Its design might help you; although, it also probably depends on motivation / what you want to teach. Anyway, that's the best I can offer. Good luck! It sounds like you're in for a fun time. :) -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issue with classes
On Tue, Jun 12, 2012 at 4:07 AM, Bod Soutar wrote:
> I confess I don't know anything about classes really so I'm probably doing
> something stupid, but can anyone point me in the right direction?
A smaller example:
def foo():
mydict = {}
bar()
print mydict
def bar():
mydict[3] = 5
Why do you suppose mydict is not visible from bar?
This is the same reason that cf is not visible from methods on your class.
-- Devin
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] str object is not callable
On Tue, Jul 10, 2012 at 10:56 AM, Chris Hare wrote: > The input to the function in the larger program is the same as the first test > in the small script that works -- "admin". > > As a side note -- the rstrip call is also broken, although the string module > is imported. I just can't figure out why this code works in one context and > not in another. I suspect you defined "bool" somewhere to be a string. That, or else you passed in a string as the search argument. Unfortunately Python doesn't tell you which expression raised the exception, but certainly it's one of those two. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] writing function changeColor
On Wed, Jul 18, 2012 at 3:20 PM, Aditi Pai wrote: > I am trying my best to learn and your attitude was not welcome. If you don't > want to answer my question, I understand. I'm doing research elsewhere too > and because I am new at this, my familiarity with key terms and search words > is also improving, yet at a slower pace. My goal is to find people who would > help me find the resources I need and not cheat, which is why I didn't want > to post my assignment. If you don't post the assignment, we don't necessarily know what advice would constitute cheating. It's especially important for university students, who can be expelled for helping other students cheat -- even if they didn't know it was cheating and the cheater was in another country at another school. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] floating point rounding inconsistency
On Fri, Sep 28, 2012 at 8:37 AM, Steven D'Aprano wrote: > On 28/09/12 22:15, Mark Lawrence wrote: > >> The Python round function is itself problematic. The idea of deprecating >> it is currently being discussed on Python ideas. This quote from Calvin >> Spealman is typical "Also, I'd be completely in support of dropping >> round() >> and agree it gets misused and leads to too much confusion. We should >> promote the right ways, and sometimes to show the right path you need to >> lock another door and throw away the key.". > > > Isn't that the same Calvin Spealman who wrote the blog post spreading FUD > that > Python was at risk of dying because, well, frankly because he was utterly > ignorant of just how much Python code is written in the places where he > thought no Python was written? > > I'm not impressed. He sprouts off about how you can't use Python on mobile > devices, when you can. What makes you think his opinions on breaking > working code just because he thinks he knows the "right ways" are any less > ignorant? I don't think the newbie mailing list is the right place to show that kind of hostility, if indeed there is a right place. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Project help
Do your own homework. -- Devin On Sat, Oct 13, 2012 at 12:55 AM, Brett Dailey wrote: > I'm working on a few projects and need some help. Here's what the first one > needs to do: > > "Credits" > 1. Create a list of strings. Make sure your program will work with any > number of strings. > 2. Make this text appear at the bottom of the screen and “crawl” to the top. > The crawl should be at a slow > speed (~20 pixels/s) and should run at the same rate on any computer. > 3. It should fade from black (near the bottom) to white, and then back to > black (at the top). > 4. The program should end when the user pressed escape or hits the > “Quit-box” > > > Here's the second one: > > "Paint Program" > 1. Display a canvas inset from the main screen. > 2. Display a palette at the bottom. Allow the user to adjust the RGB current > color. > 3. Use the mouse scroll-wheel to adjust the brush size. > 4. If the user clicks within the canvas area, draw with the current brush > color/size > 5. If the user presses “s” save (just the) canvas to a file (“output.jpg”) > 6. Bonus: include “stamps” (sprites) that can be dragged onto the canvas. > > Any help would be greatly appreciated!! These have been giving me some > trouble. Also, if you can show me some of the code that would be great! > > Thank you!! ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which is better Practice and why
On Mon, Oct 22, 2012 at 7:45 AM, Matthew Ngaha wrote: > the 2nd one usually includes a lot more code then i showed. can you please > tell me why different methods are used to access the main code? is it just > preference or is one way actually better coding practice? The second one is used if your importable modules are also scripts that can be executed. That's a bad idea, because it results in the same source file being executed twice, producing distinct classes that break typechecking. If you have "myprogram.py" containing the following source code, and execute it as a program, it will terminate with an uncaught MyError. class MyError(Exception): pass import myprogram try: raise myprogram.MyError except MyError: pass So, in any circumstance where you would use the second one, it's because you're in a situation where bad things are happening. So use the first one always. And if there's code in the script you want to share, put it in a separate module. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which is better Practice and why
On Mon, Oct 22, 2012 at 6:15 PM, Steven D'Aprano wrote: > Not that. That unconditionally executes main the first time you access > the module, *regardless* of whether it is being run as a script or > being imported. That is nearly always the wrong thing to do. Recently I've become a fan of executable packages. In __main__.py, it's always the right thing to do. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which is better Practice and why
On Mon, Oct 22, 2012 at 9:23 AM, Walter Prins wrote: > Devin, > > On 22 October 2012 12:54, Devin Jeanpierre wrote: >> On Mon, Oct 22, 2012 at 7:45 AM, Matthew Ngaha wrote: >>> the 2nd one usually includes a lot more code then i showed. can you please >>> tell me why different methods are used to access the main code? is it just >>> preference or is one way actually better coding practice? >> >> The second one is used if your importable modules are also scripts >> that can be executed. >> >> That's a bad idea, because it results in the same source file being >> executed twice, producing distinct classes that break typechecking. If >> you have "myprogram.py" containing the following source code, and >> execute it as a program, it will terminate with an uncaught MyError. >> >> class MyError(Exception): pass >> >> import myprogram >> try: raise myprogram.MyError >> except MyError: pass > > Why would you do this though? Is the source of the problem not really > that you're importing a module inside itself? Why would you generally > want to do this? Furthermore the 'if __name__ == "__main__"' idiom is > explicitly part of Python and generally well accepted (so it seems to > me at least), so the above seems like a fairly esoteric objection to > its use? It's that your module was imported, while it was executed as a script. It's fairly common for modules to import each other for various reasons. Especially if one module is executable, it might do "circular" imports for the purposes of its execution (tests or what have you), and these break because the reverse part of the "circle" actually create a new module rather than doing a circular import. This kind of behavior is pretty much impossible if your scripts are scripts, and your modules are modules. The only downside is that you have to import the code you use in your scripts. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which is better Practice and why
On Mon, Oct 22, 2012 at 8:42 PM, Steven D'Aprano wrote: > If you do that, and the module directly or indirectly imports itself > while it is running as a script, you may run into trouble. But writing > a dual-purpose module that is usable as an importable module or as a > stand-alone script is not problematic in itself. Yes. However, it is somewhat hard to guarantee that a module won't indirectly import itself for a large codebase. It certainly sometimes happens by accident. >> So use the first one always. > This is contrary to the advice given in the Fine Manual: > > http://docs.python.org/library/__main__.html > > > More from Python's creator, GvR, and the Effbot: > > http://www.artima.com/forums/flat.jsp?forum=106&thread=4829 > > http://effbot.org/pyfaq/tutor-what-is-if-name-main-for.htm It's very easy for me to overstate my case. Maybe I even have already, just because I wasn't taking very long to explain myself. I have concrete reasons to not use this form. It comes up very rarely, and is not a large issue. Heck, it's not even really worth making a big fuss over. But there is the occasional mess-up where it happens. I am also aware that what I prefer goes against idiom. But to me, this minor concrete use-case beats out idiom. After all, what is the benefit to following this particular idiom? I believe the answer is, "you get to use one .py file instead of two" -- and as I see it, the cases where circular imports might be a problem are precisely those where you don't care too much about the number of files, because you're writing a package anyway. As it happens, I sort of stumbled across this worldview when I was forced into separating modules from scripts with the new __main__ submodule system to make executable packages (So it's even possible for Pythonic code to forgo the name check). It really struck something in me, and I had a (subjective) realization that modules and scripts are fundamentally different, and that there's very little benefit to conflating them. I realize this isn't really a view that's mainstream for Python. Also, I realize it's not a particularly interesting realization -- any C# programmer would tell you this. And presumably, Pythonistas as a group would disagree. (As an aside, I find it interesting how much more beautiful GvR's code in that post becomes if you consider turning the common bits into a @main decorator). -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which is better Practice and why
On Mon, Oct 22, 2012 at 8:54 PM, Steven D'Aprano wrote: >> Recently I've become a fan of executable packages. In __main__.py, >> it's always the right thing to do. > > > I would disagree there too. I think that unconditionally running main > is the wrong thing to do, except perhaps in the most trivial quick-and- > dirty scripts. But if the script it that trivial, you might not even > bother with a main function at all. > > package.__main__.py is designed to be run as a script, and not to be > imported. But that doesn't mean that there's no good purpose for > importing it. If your package is non-trivial, you ought to have tests > for it, including package.__main__. Those tests will probably want to > import the module, not necessarily run it as a script. I think you will find that it is never the case that __name__ != '__main__' in a file called "__main__.py". If I want to test something, I put it in another file. My __main__.py file will generally look something like this: from . import game game.Game().run() -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which is better Practice and why
On Tue, Oct 23, 2012 at 5:59 AM, Steven D'Aprano wrote: > I think you'll find that you're wrong there :) Oops. >> If I want to test something, I put it in another file. > Yes. And how do you import the __main__.py module to test it, without > it executing? How do you test the body of code in the "if __name__ == '__main__'" block, without it executing? -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python and xml *creation*
On Fri, Oct 26, 2012 at 6:49 PM, Sander Sweers wrote: > Op vrijdag 26 oktober 2012 17:00:16 schreef Prasad, Ramit: >> Based on the most recent comment (May 2010) I would probably >> stick with online tutorials. > > I generally do not trust "reviews" on the publisher's website as they have > been proved to be constructed by them. Why would the publisher construct a negative review? And if it did, would you distrust it and decide that the book was actually good? >> http://www.blog.pythonlibrary.org/2012/06/06/parsing-xml-with-python-using-l >> xml-objectify/ http://wiki.python.org/moin/PythonXml >> http://eli.thegreenplace.net/2012/03/15/processing-xml-in-python-with-elemen >> ttree/ > > The first and the last are about parsing/processing existying xml. I did find > the page on the python wiki but untill now I missed the effbot page on > elementtree (it is "hidden" almost at the bottom of the page together with the > a list of books o_O). As far as lxml goes, there is also the E factory: - http://lxml.de/tutorial.html#the-e-factory - http://lxml.de/objectify.html#tree-generation-with-the-e-factory And you can create valid XML via a template via Genshi: - http://genshi.edgewall.org/wiki/GenshiTutorial -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] running multiple concurrent processes
On Sat, Nov 3, 2012 at 9:05 PM, richard kappler wrote: > I notice no one has mentioned asyncore. Is that something I should stay away > from? I just started digging through the doc file. Regardless of ones' feelings on it, there is no builtin support for multiprocessing using asyncore. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Value of tracebacks to malicious attackers?
Forgetting to hide tracebacks on a client-side app is not a huge deal (other than being confusing and looking too serious), and definitely doesn't matter for security. So I guess we're assuming that the Python code is not on the user's machine. On Sat, Jan 23, 2016 at 10:43 PM, Danny Yoo wrote: > But if there is malicious intent, yes, a traceback can give a lot of > information that we're rather not give freely. Operating system, > version of the Python runtime, locations of files, etc. That's all > valuable knowledge. Verbose tracebacks (like from cgitb) will also included the values of variables on the stack, which can include extremely sensitive data like cryptographic keys. For letting users report errors without compromising any data at all, one can give them a hashed stack trace or error ID that a developer can look up locally from an error DB. If there is no error DB, then an encrypted stack trace works too. >> Is it even >> possible to prevent this from happening? I am highly doubtful that it >> is possible to handle all possible exceptions in any reasonably >> complex application. You can catch exceptions using a top-level try-except. If an exception slips through (e.g. a bug in your setup/teardown code etc.), then your app will crash, but the exception will not be given to the user (just to stderr, which will get directed to logs), because the only exceptions users see are exceptions you explicitly give to them. (This isn't true in some environments. Avoid those.) -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Fwd: findall() returns tuples or string?
On Mon, Mar 4, 2013 at 8:22 PM, Charles Leviton wrote: > I have some confusion regarding when findall returns a list of strings and > when it returns a list of tuples. > Would appreciate an explanation. If there are no groups, it returns a list of strings, where the strings are the whole match. If there is one group, it returns a list of strings, where the strings are the content of the group. Otherwise, it returns a list of tuples of strings, where the tuples contain the group contents (the same as if an individual match had its groups() method called). If you want consistency, use finditer instead of findall. http://docs.python.org/2/library/re.html#re.finditer -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Pygraphics crashed
On Thu, May 16, 2013 at 2:06 AM, Jim Mooney wrote: > How do I uninstall modules? I installed Pygraphics, which worked fine, > along with some other mods, like numpy, but when I installed 64 bit py > 2.7 > I get the message "The _imaging C module is not installed" when > running a prog that worked fine before. I think I have a higher > dot-version - Py 2.7.4 as opposed to 2.7.3 - what's the easiest way > to fix this? Will uninstalling and reinstalling the modules do > anything or do I have to revert to an older Py (I'm on Win 7) On windows it's generally easiest to use a 32 bit Python. If you uninstall python, and install a 32 bit version and the 32 bit modules and so on, it should work. By the way, do you mind if I ask why you're using PyGraphics? It's only meant to be used for education (and even there, AFAIK the only users are the University of Toronto (and even there, I think they stopped using it because they switched to Python 3 for Coursera and didn't care enough to upgrade PyGraphics (I am mad about this))). -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Parentheses and tuples [was Re: Fwd: Difference between types]
On Fri, May 24, 2013 at 10:35 PM, Steven D'Aprano wrote: > So single-item tuples are not special. They just follow the rules for > multiple-item tuples, except that you only have item. And except that the trailing comma is not optional. So, they are special after all. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] bytecode primer, and avoiding a monster download
On Mon, May 27, 2013 at 7:20 PM, Alan Gauld wrote: > Can you give a use case of how you think you could use them? > There may be another way to do what you want. I can't speak for Jim, but I have used the dis module in the past to quickly check how python parsed an expression (e.g. not x is y). -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Opinion - help could use more examples
On Wed, Jun 19, 2013 at 1:43 PM, Jim Mooney wrote: > Here's a peeve of mine about Python help - it often has zero examples. > I printed help(zip) to see what it does and got this: > --snip-- > > Not understandable right off, IMHO, unless you're already hardcore. help() is outright harmful to people that don't already know what they're doing -- it omits things like advice to do with security, including neglecting to declare that functions are not safe and can execute arbitrary Python code, that sort of thing, but also the more common case of just minor security "footnotes" that are nonetheless important for every user to know. Definitely use the HTML docs. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Hash map and dictionaries
On Sun, Dec 1, 2013 at 7:40 AM, Reuben wrote: > Hi > > Question 1: > - > I would like to know the concept of hash map. Additionally, I got to know > that hash maps are equivalent to dictionaries in python. > > I would like to understand the relationship between dictionaries and hash > map better. Hash maps are a class of data structures which associate values with keys. They exhibit constant time average case behavior if every possible key is equally likely. They usually have O(n) worst case behavior. Python dictionaries are an implementation of hash maps using a particular choice of algorithms. > > Question 2: > -- > It is also said that in a list of may be 10,000 elements(specifically > integers), hash maps would be a better option to find the occurrence of > repetitive integers > > How can this be implemented using dictionaries for a list of 10,000 integer > elements? You would use sets, not dictionaries. x = set(range(HUGE_NUM)) # "1 in x" is as fast as "-1 in x" x = list(range(HUGE_NUM)) # "1 in x" is much faster than "-1 in x" Sets use hash tables internally too, but they don't associate a value with the keys. They just mark whether or not the key is present. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] more html/css question than python
On Sat, Dec 21, 2013 at 11:10 AM, Matthew Ngaha wrote: > so xhtml even over html5? isn't html5 the new thing these days? I know > basic javascript, so it's definately better to also learn jquery? > I've always pushed it to the side :( HTML5 has an XML representation (called XHTML5) which works even in IE. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python, speed, game programming
On Fri, Jan 3, 2014 at 1:53 PM, Keith Winston wrote: > I am gearing up for the next project (yeah, an eventual end to Chutes & > Ladders!). It is a typing tutor, I am inclined to use it to learn Dvorak but > I would expect it easily adapted to QWERTY or anything else. > [snip] > > I hope Python is a good choice here, though I suppose some modules or > classes or parts will have to be recoded into something faster... Any > thoughts on this will be appreciated, including how to structure it in such > a manner that it might be more portably applied to future versions in > entirely different knowledge realms (music/midi input, > language/vocabulary/audio output, etc). Modern computers are just so absurdly fast that the overhead Python has compared to other languages just doesn't matter for the kind of work you are doing. If you typed at a hundred characters per second Python could still keep up, unless there's something about your problem you aren't describing. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] python problems on android
On Fri, Jan 3, 2014 at 4:26 PM, wrote: > Thanks Dave. Your email doesn't appear to be in response to anything. I think your email client is broken, and you should switch to a different one. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iter class
On Wed, Jan 22, 2014 at 8:57 PM, Keith Winston wrote: > 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): > ... return self > ... > ... def next(self): > ... self.index += 1 > ... if self.index < len(self.thelist): > ... return self.thelist[self.index] > ... raise StopIteration > > FYI, this is supposed to be an example of how NOT to do an iterator, > because of the way it handles thelist (which is supposed to be an > iteratable construct, like a list, if I'm not confused). thelist is more like a sequence, meaning you can use myseq[n] for every value of n between and including 0 and len(myseq) -1. (Although, sequences usually have other things, too.) An iterable is anything you can loop over with a for loop. This is a perfectly reasonable iterator, but iterators are always tricky when used as an iterable -- you can't do a nested loop over a single iterator, because the iterator used for both loops will be the same iterator, and keep the same state. > Anyway, my efforts to recreate the following example: > mi = MyTrickyIter(['a', 'b']) for i in mi: > ... for j in mi: > ... print i, j > > which should result in > > a b > > instead results in > > Traceback (most recent call last): > File "", line 1, in > for i in mi: > TypeError: iter() returned non-iterator of type 'MyTrickyIter' > > I'm sort of wondering if there's a Py2 vs. Py3 issue here, but I don't see it. in Python 3, it should be __next__, not next. 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. ;) -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] iter class
On Thu, Jan 23, 2014 at 7:50 AM, Keith Winston wrote: > Yes, the exercise was about implementing an iter incorrectly, to see > the difference. But I don't really understand your second point: when > I changed the method name, it worked...? Again, nothing was incorrect about the example. Every iterator has this "problem". I question how good your resource is, if this is the impression it's leaving you. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Which computer operating system is best for Python
On Wed, Feb 5, 2014 at 4:35 PM, David Abbott wrote: > Linux runs great on older Laptops that were the top of the line in > their day, two nice examples with great keyboards are dell e6400 and > ibm T61's. Linux is easy to install and set up now a days :) FWIW linux does, but firefox and chrome don't. I've found that they work very poorly on older machines with little memory. I also second anyone that suggests Linux is good for learning Python. I found it a very conducive platform to learn Python on when I first learned, even as a new linux user -- it makes it really easy to get everything you need, and it encourages development practices (in particular, using a terminal, but also things like using a real text editor) that make programming easier both short- and longer- term. It's also not that hard to learn, especially for children, especially compared to Python. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] learning recursion
On Thu, Feb 6, 2014 at 11:28 AM, Denis Heidtmann wrote: for i in range(4): > ... print fib2(i) > ... > > The above results in an error: Because fib2(0) recurses infinitely, and i's first value is 0. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Question about O(N**2)
On Sat, May 3, 2014 at 9:13 PM, Steven D'Aprano wrote: > > On Sat, May 03, 2014 at 03:59:40PM -0700, Danny Yoo wrote: > > Following up on this. Let's make sure that we're talking about the same > > thing. > > > > > > The assertion is that the following: > > > > fullPath += [...] > > > > where fullPath is a list of strings, exhibits O(n^2) time. I don't > > think this is true. Semantically, the statement above should be > > equivalent to: > > > >fullPath.append(...) > > > > and so I agree with David: this is not O(n^2), but rather O(n). > > Danny is correct. For built-in lists, += augmented assignment is > implemented using the extend method, not the + operator. Consequently, > repeatedly calling += modifies the list in place, growing it as needed, > which is amortized O(N) rather than O(N**2). Nit: starting from an empty list, it's worst-case O(N), no "amortized" qualifier necessary. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How does this work? Is there anyway to receive live Python help?
If you want python help "live", try the #python IRC channel at irc.freenode.net You'll need to register a nick though, see https://freenode.net/faq.shtml#nicksetup -- Devin On Mon, May 26, 2014 at 8:40 AM, Emma Soules wrote: > > > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How does this work? Is there anyway to receive live Python help?
FWIW I am an operator on the channel, so, obviously biased. (ssbr) On Mon, May 26, 2014 at 5:15 PM, Steven D'Aprano wrote: > On Mon, May 26, 2014 at 01:04:55PM -0700, Devin Jeanpierre wrote: >> If you want python help "live", try the #python IRC channel at >> irc.freenode.net >> >> You'll need to register a nick though, see >> https://freenode.net/faq.shtml#nicksetup > > Ouch! > > #python is not very friendly to beginners. (Or anyone else for that > matter.) There are many things that are unfriendly about #python, and many things that are friendly about it. I think it's unfair to casually dismiss it as a place to learn. If Emma was who I think they were, their experience seemed fine to me, and their questions seemed suitable for IRC. > It's well-suited to questions which can be asked, and > answered, in one or two sentences, but is completely unsuitable for > extended discussion. On the contrary, I prefer #python to the mailing list for smallish but extended discussion. Because the unit of conversation is very small, and the turnaround time is so short, small misunderstandings can be quickly corrected, and the conversation progresses quickly. It is very often the case that one question leads to another, which leads to another. In IRC this is one relatively quick (but "extended") session. This is its core advantage over something like a mailing list (with its slow round-trip time), and one that I think #python uses fairly well. On the other hand, mailing lists are amazing for esoteric questions that need the right pair of eyes or they can't be answered, or for requests for extended monologues about how something works, etc. -- IRC can do these, especially the latter, but not as well. I think the fact that #python is so popular (for extended discussion, no less) shows that it is not bad, but that it might be a matter of preference. > Also they have a bad habit of banning people without warning or > explanation. And, I have to say, in my opinion often their answers are > actually *wrong*, but if you try to tell them so they ban you. You would not be banned for saying an answer is wrong. That happens all the time, because answers often are wrong. But, for example, you might be banned if you keep telling everyone "lol wow, you have no idea what you are talking about", and insulting things like that (without so much as giving an actual answer yourself). But you would probably be warned first. If you have more details, I can offer more help and/or apologies as warranted. I am only talking in the abstract, and it's possible you saw somebody be wronged. -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] What are *appropriate* uses for exec() and eval() ?
On Mon, Feb 16, 2015 at 6:15 PM, Steven D'Aprano wrote: > Here is a fork of that recipe. It uses an inner class for the new > namedtuple class. The only thing which needs exec is the __new__ method. > > http://code.activestate.com/recipes/578918-yet-another-namedtuple/ > > This demonstrates a powerful truth about Python: *most of the time* you > don't need to use exec or eval because the standard language features > are powerful enough to solve the problem for you. Using a dynamically > created inner class is *almost* enough to solve this problem, only the > __new__ method defeats it. If our requirements where just a little less > demanding, we could avoid exec completely. No, exec is not necessary at all. If they had to the author could have reimplemented the argument assignment logic by hand. They chose not to because it is "too hard". (And it is.) Fortunately, they don't have to go that far: signature = inspect.Signature([ inspect.Parameter(field_name, inspect.Parameter.POSITIONAL_OR_KEYWORD) for field_name in field_names]) def __new__(cls, *args, **kwargs): return tuple.__new__(cls, signature.bind(*args, **kwargs).arguments.values()) -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] What are *appropriate* uses for exec() and eval() ?
On Mon, Feb 16, 2015 at 7:20 PM, Cameron Simpson wrote:
> One might use exec() to use code that is valid in one python version but not
> another, when you need your program to run in both i.e. to get code that is
> syntacticly invalid in one version, but to use it (conditionally) in another
> version.
>
> I only have one use case for this presently: I have a use of exec() in my
> cs.py3 python2/3 compatability module:
>
> def raise3(exc_type, exc_value, exc_traceback):
>if sys.hexversion >= 0x0300:
> raise exc_type(exc_value).with_traceback(exc_traceback)
>else:
> # subterfuge to let this pass a python3 parser; ugly
> exec('raise exc_type, exc_value, exc_traceback')
>
> I'm using exec() here because a Python 3 interpreter will reject the 3
> argument form of raise. Elsewhere in my code I just call cs.py3.raise3()
> with the requisite arguments. Note that the string passed to exec() is
> hardwired, not obtained from elsewhere in any form.
I'd try conditional imports, first:
if sys.hexversion >= ...:
from .compat_py3 import raise3
else:
from .compat_py2 import raise3
But maybe this breaks with the setuptools pre-compilation shenanigans?
At any rate, I didn't mean to make a general statement. Obviously,
sometimes exec/eval is necessary. If for no other reason than because
sometimes the requirement is to use exec (e.g. if you are implementing
something equivalent to python -i, etc.).
-- Devin
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] What are *appropriate* uses for exec() and eval() ?
On Tue, Feb 17, 2015 at 7:31 AM, Steven D'Aprano wrote: > On Mon, Feb 16, 2015 at 07:10:21PM -0800, Devin Jeanpierre wrote: >> On Mon, Feb 16, 2015 at 6:15 PM, Steven D'Aprano wrote: >> > Here is a fork of that recipe. It uses an inner class for the new >> > namedtuple class. The only thing which needs exec is the __new__ method. >> > >> > http://code.activestate.com/recipes/578918-yet-another-namedtuple/ >> > >> > This demonstrates a powerful truth about Python: *most of the time* you >> > don't need to use exec or eval because the standard language features >> > are powerful enough to solve the problem for you. Using a dynamically >> > created inner class is *almost* enough to solve this problem, only the >> > __new__ method defeats it. If our requirements where just a little less >> > demanding, we could avoid exec completely. >> >> No, exec is not necessary at all. > > I'm not sure that I said that exec was "necessary" anywhere, You said that most of the time you don't "need" to use it. You then explained how you narrowly had to use exec in this case, and could have avoided it if the restrictions were relaxed. That sure sounds like you were saying it was necessary. Maybe you meant to say something else? > but since > you mention it, how about the two earlier examples I gave, timeit and > doctest? Especially doctest. How would you implement doctests without > exec? I already covered this in my response to Cameron: I only meant that in this particular case exec is not needed. >> If they had to the author could have >> reimplemented the argument assignment logic by hand. They chose not to >> because it is "too hard". (And it is.) Fortunately, they don't have >> to go that far: >> >> signature = inspect.Signature([ >> inspect.Parameter(field_name, inspect.Parameter.POSITIONAL_OR_KEYWORD) >> for field_name in field_names]) > > Hmmm. Well, namedtuple was added to Python in version 2.6. [snip] > So much for that idea. What? Why should what was impossible in the past stop you from doing what is possible now? -- Devin ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
