Re: GitHub's ³pull request² is proprietary lock-in
Christian Gollwitzer writes: > Arguably, the most valuable outcome of the pull request in the end is > the patch, which is of course contained in the git repository. Arguably, the most valuable outcome of a database system is the query result, which is of course contained in the result set of tuples contained in the response data. Arguably, the most valuable outcome of a version control system is the source code tree, which is of course contained in a filesystem directory. Arguably, the most valuable outcome of a programming language is the programs we write with it, which is of course contained in the compiled binary. By your reasoning, that means we should not care about handing the control over our database system, our version control system, or our programming language to a vendor-locked, proprietary, gratuitously centralised technology. I hope the analogy makes it clear why that's not an argument I think anyone would accept as sound. > I doubt that many people want to go back to see the arguments for a > certain merge I doubt many people want to go into the source code for my operating system and tell me exactly what it's doing, where my data is stored, how to get it from this operating system to a different one. My freedom to migrate from that system to a different one when I choose, is entirely dependent on *anyone* being able to do that, no matter how few people express an interest where you might see it. -- \ “There's no excuse to be bored. Sad, yes. Angry, yes. | `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, | _o__) ever.” —Viggo Mortensen | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Am 03.01.16 um 09:03 schrieb Ben Finney: Christian Gollwitzer writes: Arguably, the most valuable outcome of the pull request in the end is the patch, which is of course contained in the git repository. Arguably, the most valuable outcome of a database system is the query result, which is of course contained in the result set of tuples contained in the response data. Arguably, the most valuable outcome of a version control system is the source code tree, which is of course contained in a filesystem directory. Arguably, the most valuable outcome of a programming language is the programs we write with it, which is of course contained in the compiled binary. By your reasoning, that means we should not care about handing the control over our database system, our version control system, or our programming language to a vendor-locked, proprietary, gratuitously centralised technology. I hope the analogy makes it clear why that's not an argument I think anyone would accept as sound. There are layers. Below your Python code there is CPython, below that the C compiler, the OS, and finally the hardware. If you are using an Intel CPU, you can't control the interpreter of the x86-64 machine opcodes. At some point, nobody cares. It's a question where to put the border. In former times, people sent emails with patches attached. Nobody complains that those emails are lost to the community. Then somebody invented VCS and all became better. Pull requests are nothing but elaborated emails. I doubt that many people want to go back to see the arguments for a certain merge I doubt many people want to go into the source code for my operating system and tell me exactly what it's doing, where my data is stored, how to get it from this operating system to a different one. My freedom to migrate from that system to a different one when I choose, is entirely dependent on *anyone* being able to do that, no matter how few people express an interest where you might see it. You can still migrate, because git stays git. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: (Execution) Termination bit, Alternation bit.
On Sun, 3 Jan 2016 12:18 pm, Skybuck Flying wrote: > Should be easy to turn that somewhat pseudo code into python code ! :) If it is so easy, why won't you do it? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Christian Gollwitzer writes: > There are layers. Below your Python code there is CPython, below that > the C compiler, the OS, and finally the hardware. Yes. There are continual motivations to take the technology at any of those levels and make it less free, make it more locked to single vendors, make it more difficult to migrate our valuable data to a system under our control. Asserting that one level is currently less free, is in no measure an argument to allow a different level to be moved further from the community's control. > At some point, nobody cares. You clearly do care, since you are participating in this discussion and attempting to argue that people *should not* care. > In former times, people sent emails with patches attached. Nobody > complains that those emails are lost to the community. You make my point for me: Nothing about that method of transferring code changes was actively controlled by a single vendor, nor gratuitously centralised, nor handed to an unexaminable, unaccountable system. > Then somebody invented VCS and all became better. Pull requests are > nothing but elaborated emails. Email is decentralised; it has no gratuitous barriers between diverse implementations of the standards; it has standards that are energetically guarded against vendor lock-in. Anyone can take email data from the email server, migrate it to a different implementation of the same email system, keep it running with the same data and allow the same people to continue interacting with it as before. Those are traits I think a community should require of any system that controls vital discussions like pull requests. If GitHub pull requests could be verified to work that way, I would have no complaint here. Until they do, it is foolish for a community to willingly put their correspondence data into it. -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney wrote: > Anyone can take email data from the email server, migrate it to a > different implementation of the same email system, keep it running with > the same data and allow the same people to continue interacting with it > as before. > > Those are traits I think a community should require of any system that > controls vital discussions like pull requests. > > If GitHub pull requests could be verified to work that way, I would have > no complaint here. Until they do, it is foolish for a community to > willingly put their correspondence data into it. They are. Ultimately, a GitHub pull request is backed by a git pull request. Here's an example: https://github.com/MikeiLL/appension/pull/187 That's a request to pull https://github.com/Rosuav/appension's log_to_file branch (https://github.com/Rosuav/appension/tree/log_to_file) into the master branch. That can be fetched and merged into a local repository: git pull https://github.com/Rosuav/appension log_to_file If the official workflow is built on these commands, then it doesn't depend on GitHub at all. Someone puts through a GH PR and it'll create an email that provides all the necessary info; but equally, someone can use any other git hosting and send through an identical pull request without ever touching GH. Since actual bug discussion isn't being moved away from bugs.python.org, this should be safe. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Chris Angelico writes: > They are. Ultimately, a GitHub pull request is backed by a git pull > request. There is no such thing as a "git pull request", except in the ordinary english meaning of the word request. It is true that a pull request is, from one angle, a formalized request for someone to execute a git pull command. But there is no command to create a "pull request", nowhere for such a thing to exist in the repository, etc. It is, in essence, a parallel bug tracker, with its own discussion system, its own statuses, etc. > Here's an example: > > https://github.com/MikeiLL/appension/pull/187 > > That's a request to pull https://github.com/Rosuav/appension's > log_to_file branch > (https://github.com/Rosuav/appension/tree/log_to_file) into the master > branch. That can be fetched and merged into a local repository: > > git pull https://github.com/Rosuav/appension log_to_file > > If the official workflow is built on these commands, then it doesn't > depend on GitHub at all. Someone puts through a GH PR and it'll create > an email that provides all the necessary info; but equally, someone > can use any other git hosting and send through an identical pull > request without ever touching GH. When I tried github it was also very unclear how someone can pull to a github repository from a source other than another github repository with an associated github pull request. I suppose they could pull into their local repository and then push to github. Also if someone puts through a github pull request and then their patch is accepted, my understanding is that the pull request has to be "closed" through a github online interface and merely merging the patch through the git command line will not update the status on the pull request. > Since actual bug discussion isn't > being moved away from bugs.python.org, this should be safe. I don't think you can really narrow "actual bug discussion" like that. Some discussion takes place on the bug tracker, some discussion takes place here, some discussion takes place on python-ideas, some discussion takes place on other mailing lists... and it's suspected that some discussion will take place on github. All of that discussion has value, and it's not good to have any of it locked up in a place that cannot be exported. -- https://mail.python.org/mailman/listinfo/python-list
Re: [python] Re: GitHub's ³pull request² is proprietary lock-in
On Sun, Jan 03, 2016 at 04:31:55AM -0500, Random832 wrote: > But there is no command to create a "pull request", nowhere for such > a thing to exist in the repository, etc. There is this [1]. > Also if someone puts through a github pull request and then their > patch is accepted, my understanding is that the pull request has to > be "closed" through a github online interface and merely merging the > patch through the git command line will not update the status on the > pull request. This is incorrect. GitHub will automatically mark PRs as “Merged” when their tip commit lands in the target branch. I haven't looked up docs for when this landed (if it was even announced), but next to GitHub's “Merge pull request” button there's currently an “or view command line instructions” link which sketches out some command-line Git to accomplish the same thing. But I agree that it's nice to keep the discussion around pull requests somewhere portable. Cheers, Trevor [1]: http://git-scm.com/docs/git-request-pull -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Chris Angelico writes: > On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney wrote: > > Anyone can take email data from the email server, migrate it to a > > different implementation of the same email system, keep it running > > with the same data and allow the same people to continue interacting > > with it as before. > > > > Those are traits I think a community should require of any system > > that controls vital discussions like pull requests. > > They are. Ultimately, a GitHub pull request is backed by a git pull > request. Here's an example: > > https://github.com/MikeiLL/appension/pull/187 Yes, of course the VCS data is in Git and therefore can be accessed with Git. Please stop raising that when *I'm not talking about* the VCS data alone, I'm talking also about the data of the pull request feature. The discussion data, code review data, etc. is all part of “GitHub pull request”. How do we export, along with the VCS data, the data and system that control the code review discussino and other useful features entailed by “GitHub pull request”? How do we get that data and confidently and quickly set up a system hosted on a different provider that allows everyone involved to continue the same code reviews and discussions etc. without GitHub? To my knowledge we can't, short of re-implementing an expressly proprietary non-standard system against the wishes of the vendor. That's valuable community data being locked into a single-vendor system, who explicitly rejects community access to the system and the data needed to continue on a different provider. It boggles my mind that so many people – even when the conversation has directly raised the notion of different layers of technology that control different layers of valuable data – blithely ignore the fact that *the discussion itself* is dependent on a software system and data. Control over that software system and data is important to control over the valuable discussions, just as control over the VCS system and data is important to control over the valuable source code. Conversely, as Ned Batchelder points out, without all the proprietary vendor lock-in centralised features, GitHub is a fairly unimpressive Git hosting provider. The “but Git is free software, no one is locked in!” is trivially true, and has an obvious response in “then there's no good reason to move anything there”. Please, those who are going to advocate for GitHub especially over other Git hosting providers because it has specially valuable features, be honest that you're advocating moving control of valuable information away from the community that values them. -- \ “First things first, but not necessarily in that order.” —The | `\ Doctor, _Doctor Who_ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Random832 writes: > All of that discussion has value, and it's not good to > have any of it locked up in a place that cannot be exported. I have a dim recollection of Python moving from Trac to a proprietary, hosted bug tracker for a while, but now they're back to an open(?) system but are about to do the same thing with Github. It's ironic that Git itself was written to escape the debacle of the Linux kernel using hosted (Bitkeeper) source control for a while. As for patch review discussions, didn't Guido himself write Gerrit? Somehow it's never been mentioned here. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
On Sun, Jan 3, 2016 at 8:46 PM, Ben Finney wrote: > Chris Angelico writes: > >> On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney >> wrote: >> > Anyone can take email data from the email server, migrate it to a >> > different implementation of the same email system, keep it running >> > with the same data and allow the same people to continue interacting >> > with it as before. >> > >> > Those are traits I think a community should require of any system >> > that controls vital discussions like pull requests. >> >> They are. Ultimately, a GitHub pull request is backed by a git pull >> request. Here's an example: >> >> https://github.com/MikeiLL/appension/pull/187 > > Yes, of course the VCS data is in Git and therefore can be accessed with > Git. Please stop raising that when *I'm not talking about* the VCS data > alone, I'm talking also about the data of the pull request feature. Uh, that's a pull request link. I'm talking specifically about the pull request feature here. > The discussion data, code review data, etc. is all part of “GitHub pull > request”. How do we export, along with the VCS data, the data and system > that control the code review discussino and other useful features > entailed by “GitHub pull request”? > > How do we get that data and confidently and quickly set up a system > hosted on a different provider that allows everyone involved to continue > the same code reviews and discussions etc. without GitHub? That's why I talked about what it's like if discussion continues to happen on b.p.o. Which is the current proposal. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
On Sun, Jan 3, 2016 at 8:31 PM, Random832 wrote: > Chris Angelico writes: >> They are. Ultimately, a GitHub pull request is backed by a git pull >> request. > > There is no such thing as a "git pull request", except in the > ordinary english meaning of the word request. It is true that a > pull request is, from one angle, a formalized request for someone > to execute a git pull command. But there is no command to create > a "pull request", nowhere for such a thing to exist in the > repository, etc. As Trevor mentioned, git does have such a thing - it's not as well known as some other uses of the term, but it definitely does exist. Ultimately, though, it's simply a request: "please pull from here". There's not a lot to store. > When I tried github it was also very unclear how someone can pull > to a github repository from a source other than another github > repository with an associated github pull request. I suppose they > could pull into their local repository and then push to github. If you're not using a GitHub PR, then what you're doing is using GH to host your repository. So yes, you pull into your local repo and then push to GH. That's exactly what you'd do with pretty much any other workflow; currently, how would a core committer apply a patch to CPython? Apply it locally, then push. DVCSes pretty much exclusively work that way. > Also if someone puts through a github pull request and then their > patch is accepted, my understanding is that the pull request has > to be "closed" through a github online interface and merely > merging the patch through the git command line will not update the > status on the pull request. GitHub is smart enough to recognize a straight-forward merge; otherwise (maybe you cherry-picked some commits only, or something), you can use standard notation like "Closes #1234" to signal what you're doing. But... >> Since actual bug discussion isn't >> being moved away from bugs.python.org, this should be safe. ... this is still true. > I don't think you can really narrow "actual bug discussion" like > that. Some discussion takes place on the bug tracker, some > discussion takes place here, some discussion takes place on > python-ideas, some discussion takes place on other mailing > lists... and it's suspected that some discussion will take place > on github. All of that discussion has value, and it's not good to > have any of it locked up in a place that cannot be exported. Sure, some discussion takes place on mailing lists. And I'm sure some of the discussion takes place on IRC, and in elevators on the way up to the 34th floor of some building somewhere. Are we going demand a logging IRCbot, and panic because we still can't capture the latter? No. If the discussion is important enough to be kept, it can be done on a place that's designed for keeping it: b.p.o. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Chris Angelico writes: > If you're not using a GitHub PR, then what you're doing is using GH to > host your repository. So yes, you pull into your local repo and then > push to GH. What's the point of GH in that situation? -- https://mail.python.org/mailman/listinfo/python-list
Re: Trailing zeros of 100!
On 02/01/16 17:56, Robin Koch wrote: > Am 02.01.2016 um 17:09 schrieb Tony van der Hoff: >> On 02/01/16 16:57, Robin Koch wrote: >>> sum([int(0.2**k*n) for k in range(1, int(log(n, 5))+1)]) >> >> But did you actually test it? > > Yes, should work for n >= 1. > > Why do you ask? > >From your original post: How about: >>> from math import log >>> sum([int(0.2**k*n) for k in range(1, int(log(n, 5))+1)]) That would never work; n is undefined. Now, you may have left that as an exercise for the reader, but without warning, for an obvious newbie such as the OP, that would have been unnecessarily confusing. -- Tony van der Hoff | mailto:[email protected] Ariège, France | -- https://mail.python.org/mailman/listinfo/python-list
Ajax Request + Write to Json Extremely Slow (Webpage Crawler)
I'm editing a simple scraper that crawls a Youtube video's comment page. The crawler uses Ajax to page through comments on the page (infinite scroll) and then saves them to a json file. Even with small number of comments (< 5), it still takes 3+ min for the comments to be added to the json file. I've tried including requests-cache and using ujson instead of json to see if there are any benefits but there's no noticeable difference. You can view the code here: http://stackoverflow.com/questions/34575586/how-to-speed-up-ajax-requests-python-youtube-scraper I'm new to Python so I'm not sure where the bottlenecks are. The finished script will be used to parse through 100,000+ comments so performance is a large factor. -Would using multithreading solve the issue? And if so how would I refactor this to benefit from it? -Or is this strictly a network issue? Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin wrote: > Chris Angelico writes: >> If you're not using a GitHub PR, then what you're doing is using GH to >> host your repository. So yes, you pull into your local repo and then >> push to GH. > > What's the point of GH in that situation? Mainly hosting, plus you can use gh-pages and other features. Plenty. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Consistent error
Good day, please I'm writing the algorithm below in python but unittest keeps giving error no matter how i rewrite it. This is the algorithm: Create a function get_algorithm_result to implement the algorithm below Get a list of numbers L1, L2, L3LN as argument Assume L1 is the largest, Largest = L1 Take next number Li from the list and do the following If Largest is less than Li Largest = Li If Li is last number from the list then return Largest and come out Else repeat same process starting from step 3 Create a function prime_number that does the following Takes as parameter an integer and Returns boolean value true if the value is prime or Returns boolean value false if the value is not prime Here's my code in python : def get_algorithm_result( numlist ): largest = numlist[0] i = 1 while ( i < len(numlist) ): if ( largest < numlist[i]): largest = numlist[i] i = i + 1 numlist[i] = numlist[-1] return largest numlist = [1,2,3,4,5] largest = get_algorithm_result(numlist) print largest def prime_number(x): return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 With this code it gives error message saying failure in test_maximum_number_two Then when I remove the numlist[i] = numlist[-1] The error message becomes failure in test_maximum_number_one (Using unit test) Please help, what am I writing wrong? Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
On Mon, Jan 4, 2016 at 1:35 AM, wrote: > Here's my code in python : > > def get_algorithm_result( numlist ): > largest = numlist[0] > i = 1 > while ( i < len(numlist) ): >if ( largest < numlist[i]): > largest = numlist[i] > i = i + 1 > numlist[i] = numlist[-1] > return largest > numlist = [1,2,3,4,5] > largest = get_algorithm_result(numlist) > print largest > def prime_number(x): > return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 I'm a bit uncertain of your indentation here, partly because there's so little of it; what happens in the while loop if the 'if' condition is false? After a 'return' statement, nothing will be executed. If you write code like this: if some_condition: do_stuff() return something do_more_stuff() the second call will never happen - the function will immediately bail out. Maybe you meant for the subsequent code to be unindented? I'm not sure. Have a very careful read of your requirements, and try to lay your code out the exact same way. Put comments against each block of code to show which part of the required algorithm it's performing. That way, you divide the problem up some, and you can look at each piece separately. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's �pull request� is proprietary lock-in
On 01/02/2016 09:56 PM, Michael Vilain wrote: > Seriously, don't like git and the gitflow, find a project where they do > things more to your liking. I do like git and the git work-flow. Seems like github is doing an end-run around several of the key features of git and the git work-flow to keep people from going outside their environment. This is definitely not the work flow Linus originally had in mind, though he is not terribly upset about it all as I think kernel development is now exclusively on github. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's �pull request� is proprietary lock-in
On 01/03/2016 08:09 AM, Bernardo Sulzbach wrote: > On Sun, Jan 3, 2016 at 1:05 PM, Michael Torrie wrote: >> kernel development is now exclusively on github. >> > > No it is not. If they have (now) 88 PR is because people don't RTFM. Good to know. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ajax Request + Write to Json Extremely Slow (Webpage Crawler)
On Sun, 3 Jan 2016 10:03 pm, [email protected] wrote: > I'm editing a simple scraper that crawls a Youtube video's comment page. > The crawler uses Ajax to page through comments on the page (infinite > scroll) and then saves them to a json file. Even with small number of > comments (< 5), it still takes 3+ min for the comments to be added to the > json file. > > I've tried including requests-cache and using ujson instead of json to see > if there are any benefits but there's no noticeable difference. Before making random changes to the code to see if it speeds it up, try running it under the profiler and see what it says. https://pymotw.com/2/profile/index.html#module-profile https://docs.python.org/2/library/profile.html > You can view the code here: > http://stackoverflow.com/questions/34575586/how-to-speed-up-ajax-requests-python-youtube-scraper I see that you already have an answer that you should try using threads since the process is I/O bound. (The time taken is supposedly dominated by the time it takes to download data from the internet.) That may be true, but I also see something which *may* be a warning sign: while page_token: [...] page_token, html = response reply_cids += extract_reply_cids(html) `reply_cids` is a list, and repeatedly calling += on a list *may* be slow. If += is implemented the naive way, as addition and assignment, it probably will be slow. This may entirely be a red herring, but if it were my code, I'd try replacing that last line with: reply_cids.extend(extract_reply_cids(html)) and see if it makes any difference. If it doesn't, you can keep the new version or revert back to the version using +=, entirely up to you. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
Thanks Chris! Don't worry about the indent, will fix it I've rewritten it to this- def get_algorithm_result( numlist ): > largest = numlist[0] > i = 1 > while ( i < len(numlist) ): i = i + 1 >if ( largest < numlist[i]): > largest = numlist[i] > numlist[i] = numlist[-1] > numlist = [1,2,3,4,5] return largest > def prime_number(x): > return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 But it still gives the test_maximum_number_one error. Please if you have any ideas what else I should change or add, let me know. Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
On Mon, Jan 4, 2016 at 2:59 AM, wrote: > Thanks Chris! > Don't worry about the indent, will fix it > I've rewritten it to this- > > def get_algorithm_result( numlist ): >> largest = numlist[0] >> i = 1 >> while ( i < len(numlist) ): > i = i + 1 >>if ( largest < numlist[i]): >> largest = numlist[i] >> numlist[i] = numlist[-1] >> numlist = [1,2,3,4,5] >return largest >> def prime_number(x): >> return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 > > But it still gives the test_maximum_number_one error. > Please if you have any ideas what else I should change or add, let me know. > Thanks! Well, the algorithmic comments I mentioned would still help you to figure out what's going on :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
On Sun, Jan 3, 2016 at 8:59 AM, wrote: > Thanks Chris! > Don't worry about the indent, will fix it > I've rewritten it to this- > > def get_algorithm_result( numlist ): >> largest = numlist[0] >> i = 1 >> while ( i < len(numlist) ): > i = i + 1 >>if ( largest < numlist[i]): >> largest = numlist[i] >> numlist[i] = numlist[-1] >> numlist = [1,2,3,4,5] >return largest This is even harder to read than before since some of the lines are now quoted and some are not. >> def prime_number(x): >> return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 > > But it still gives the test_maximum_number_one error. > Please if you have any ideas what else I should change or add, let me know. > Thanks! It's hard to give any specific advice about fixing the unittest failure without knowing what the test is testing. These two lines don't seem to have anything to do with the algorithm that you quoted in the first post, however: > numlist[i] = numlist[-1] > numlist = [1,2,3,4,5] It looks like you should kill everything in this function after the assignment to largest and then start reimplementing the algorithm again from the " If Li is last number from the list" step. -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
On Sunday, January 3, 2016 at 5:14:33 PM UTC+1, Chris Angelico wrote: > On Mon, Jan 4, 2016 at 2:59 AM, wrote: > > Thanks Chris! > > Don't worry about the indent, will fix it > > I've rewritten it to this- > > > > def get_algorithm_result( numlist ): > >> largest = numlist[0] > >> i = 1 > >> while ( i < len(numlist) ): > > i = i + 1 > >>if ( largest < numlist[i]): > >> largest = numlist[i] > >> numlist[i] = numlist[-1] > >> numlist = [1,2,3,4,5] > >return largest > >> def prime_number(x): > >> return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 > > > > But it still gives the test_maximum_number_one error. > > Please if you have any ideas what else I should change or add, let me know. > > Thanks! > > Well, the algorithmic comments I mentioned would still help you to > figure out what's going on :) > > ChrisA Thanks Chris! You possess great knowledge I'd like to have... ... well I'm just a newbie... -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
On Sunday, January 3, 2016 at 5:28:49 PM UTC+1, Ian wrote: > On Sun, Jan 3, 2016 at 8:59 AM, wrote: > > Thanks Chris! > > Don't worry about the indent, will fix it > > I've rewritten it to this- > > > > def get_algorithm_result( numlist ): > >> largest = numlist[0] > >> i = 1 > >> while ( i < len(numlist) ): > > i = i + 1 > >>if ( largest < numlist[i]): > >> largest = numlist[i] > >> numlist[i] = numlist[-1] > >> numlist = [1,2,3,4,5] > >return largest > > This is even harder to read than before since some of the lines are > now quoted and some are not. > > >> def prime_number(x): > >> return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 > > > > But it still gives the test_maximum_number_one error. > > Please if you have any ideas what else I should change or add, let me know. > > Thanks! > > It's hard to give any specific advice about fixing the unittest > failure without knowing what the test is testing. These two lines > don't seem to have anything to do with the algorithm that you quoted > in the first post, however: > > > numlist[i] = numlist[-1] > > numlist = [1,2,3,4,5] > > It looks like you should kill everything in this function after the > assignment to largest and then start reimplementing the algorithm > again from the " If Li is last number from the list" step. Thanks Ian! The algorithm is actually two part question, that's why the prime number part in the answer. And good enough that part isn't raising any errors. Still going over it hoping to get it right. Appreciate your input, God bless! -- https://mail.python.org/mailman/listinfo/python-list
Re: Consistent error
On 03/01/16 16:55, [email protected] wrote: On Sunday, January 3, 2016 at 5:14:33 PM UTC+1, Chris Angelico wrote: On Mon, Jan 4, 2016 at 2:59 AM, wrote: Thanks Chris! Don't worry about the indent, will fix it I've rewritten it to this- def get_algorithm_result( numlist ): largest = numlist[0] i = 1 while ( i < len(numlist) ): i = i + 1 if ( largest < numlist[i]): largest = numlist[i] numlist[i] = numlist[-1] numlist = [1,2,3,4,5] return largest def prime_number(x): return len([n for n in range(1, x + 1) if x % n == 0]) <= 2 But it still gives the test_maximum_number_one error. Please if you have any ideas what else I should change or add, let me know. Thanks! Well, the algorithmic comments I mentioned would still help you to figure out what's going on :) ChrisA Thanks Chris! You possess great knowledge I'd like to have... ... well I'm just a newbie... this is why Criss has given you an indication on where to start with debugging your code. Had he simply given you corrected code you would not necessarily learn why. you learn much ore when things go wrong & you fix them that you ever will buy simply having correct code. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
On 1/2/16 11:43 PM, Ben Finney wrote: That and other vendor-locked workflow aspects of GitHub makes it a poor choice for communities that want to retain the option of control over their processes and data. The Tcl community has moved to Fossil with great success: http://www.fossil-scm.org Lightweight DCVS, integrated bug tracking, rock-solid code (authored by D. Richard Hipp, uses SQLite as its store). The transition was non-trivial: the Tcl core developers had to move over a decade of commit history from CVS at Sourceforge to Fossil, which they did, successfully. One of the reasons Fossil was chosen is exactly this: to maintain the code independent of a third-party platform. (At the time of the transition, in 2011, Sourceforge was removing support for CVS, they had a server outage for over a week, and other issues were giving the community pause on continuing to use SF for hosting.) I'm not a hardcore Git user so have no substantive opinions on the merits of Git or Github per se: I have a Github account and have contributed code via pull requests to projects hosted on it. But I found learning Fossil very simple. And using Fossil does not preclude mirroring the codebase in Git; there is a Tcl/Tk mirror at Github. Just a thought. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
What use of 'sum' in this line code?
Hi, I find below code snippet on line: // m = 10 theta_A = 0.8 theta_B = 0.3 theta_0 = [theta_A, theta_B] coin_A = bernoulli(theta_A) coin_B = bernoulli(theta_B) xs = map(sum, [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), coin_B.rvs(m)]) / I see [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), coin_B.rvs(m)] is simply a list, but I don't know what use of 'sum' in this line. I replace the random number with a simple list: /// yy=map(sum, [13, 22, 33, 41]) In [24]: yy Out[24]: [13, 22, 33, 41] /// I don't see 'sum' has any effect above. The code source is from: #http://people.duke.edu/~ccc14/sta-663/EMAlgorithm.html What could you help me on the 'sum'? Thanks, -- https://mail.python.org/mailman/listinfo/python-list
Re: What use of 'sum' in this line code?
On Mon, 4 Jan 2016 11:28 am, Robert wrote: > Hi, > > I find below code snippet on line: > > > // > m = 10 > theta_A = 0.8 > theta_B = 0.3 > theta_0 = [theta_A, theta_B] > > coin_A = bernoulli(theta_A) > coin_B = bernoulli(theta_B) > > xs = map(sum, [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), > coin_B.rvs(m)]) / > > I see > [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), > [coin_B.rvs(m)] > > is simply a list, A list of what? Without knowing what coin_A.rvs(m) returns, it is impossible to know what sum will do. > but I don't know what use of 'sum' in this line. > I replace the random number with a simple list: > /// > yy=map(sum, [13, 22, 33, 41]) > In [24]: yy > Out[24]: [13, 22, 33, 41] I do not get that result. I get an error: py> yy = map(sum, [13, 22, 33, 41]) Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable Try replacing the list-of-mystery-things with a list of lists: map(sum, [[1, 2, 3], [4, 5, 6], [7, 8, 9]]) and see what you get. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What use of 'sum' in this line code?
Robert writes: > I find below code snippet on line: > > // > m = 10 > theta_A = 0.8 > theta_B = 0.3 > theta_0 = [theta_A, theta_B] > > coin_A = bernoulli(theta_A) > coin_B = bernoulli(theta_B) > > xs = map(sum, [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), > coin_A.rvs(m), coin_B.rvs(m)]) > / > > I see > [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), coin_B.rvs(m)] > > is simply a list, but I don't know what use of 'sum' in this line. > I replace the random number with a simple list: > /// > yy=map(sum, [13, 22, 33, 41]) > > In [24]: yy > Out[24]: [13, 22, 33, 41] > /// > > I don't see 'sum' has any effect above. map applies the first argument (sum) to the elements of the second. You won't see any effect unless these elements are sequences that can be summed. For example: map(sum, [[1, 2], [2, 3], [3, 4]]) bernoulli(theta_A) is a statistical distribution, with the parameter frozen in ready to have samples drawn from it. coin_A.rvs(10) requests 10 random variates from the distribution -- it's an array containing ten 0/1 elements. Thus the map(sum, ...) call does have an array or array to work with. [Not being a Python expect I've probably got some of the terminology wrong but I hope the gist of it clear.] -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
Just as a general comment, I note there are now at least four mangled versions of this subject header, and threading is already fragile enough on this list. I think in the future it would be best to avoid non-ASCII characters in subject lines. -- https://mail.python.org/mailman/listinfo/python-list
Re: What use of 'sum' in this line code?
Robert wrote: > Hi, > > I find below code snippet on line: > > > // > m = 10 > theta_A = 0.8 > theta_B = 0.3 > theta_0 = [theta_A, theta_B] > > coin_A = bernoulli(theta_A) > coin_B = bernoulli(theta_B) > > xs = map(sum, [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), > coin_B.rvs(m)]) / > > I see > [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), > [coin_B.rvs(m)] > > is simply a list, but I don't know what use of 'sum' in this line. > I replace the random number with a simple list: > /// > yy=map(sum, [13, 22, 33, 41]) > > In [24]: yy > Out[24]: [13, 22, 33, 41] > /// > > I don't see 'sum' has any effect above. > The code source is from: > #http://people.duke.edu/~ccc14/sta-663/EMAlgorithm.html > > > What could you help me on the 'sum'? >>> import numpy >>> values = [13, 22, 33, 41] >>> map(numpy.sum, values) [13, 22, 33, 41] >>> values2 = [[1, 2], [3, 4]] >>> map(numpy.sum, values2) [3, 7] In Python 2 map(sum, values) applies sum to every value in the list and returns the resulting list of sums. Apparently the numpy developers found it convenient that sum(scalar) == scalar holds. -- https://mail.python.org/mailman/listinfo/python-list
Re: What use of 'sum' in this line code?
On Sunday, January 3, 2016 at 7:54:13 PM UTC-5, Peter Otten wrote: > Robert wrote: > > > Hi, > > > > I find below code snippet on line: > > > > > > // > > m = 10 > > theta_A = 0.8 > > theta_B = 0.3 > > theta_0 = [theta_A, theta_B] > > > > coin_A = bernoulli(theta_A) > > coin_B = bernoulli(theta_B) > > > > xs = map(sum, [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), > > coin_B.rvs(m)]) / > > > > I see > > [coin_A.rvs(m), coin_A.rvs(m), coin_B.rvs(m), coin_A.rvs(m), > > [coin_B.rvs(m)] > > > > is simply a list, but I don't know what use of 'sum' in this line. > > I replace the random number with a simple list: > > /// > > yy=map(sum, [13, 22, 33, 41]) > > > > In [24]: yy > > Out[24]: [13, 22, 33, 41] > > /// > > > > I don't see 'sum' has any effect above. > > The code source is from: > > #http://people.duke.edu/~ccc14/sta-663/EMAlgorithm.html > > > > > > What could you help me on the 'sum'? > > >>> import numpy > >>> values = [13, 22, 33, 41] > >>> map(numpy.sum, values) > [13, 22, 33, 41] > >>> values2 = [[1, 2], [3, 4]] > >>> map(numpy.sum, values2) > [3, 7] > > In Python 2 map(sum, values) applies sum to every value in the list and > returns the resulting list of sums. Apparently the numpy developers found it > convenient that sum(scalar) == scalar holds. Thanks, all you say are correct in one way or the other. I just notice that it uses coin_A.rvs(m) (m=10). Thus, it sums 10 random numbers. -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano wrote: > But I think it is a real issue. I believe in beautiful tracebacks that give > you just the right amount of information, neither too little nor two much. > Debugging is hard enough with being given more information than you need > and having to decide what bits to ignore and which are important. It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how to wade tracebacks -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: > On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano wrote: >> But I think it is a real issue. I believe in beautiful tracebacks that give >> you just the right amount of information, neither too little nor two much. >> Debugging is hard enough with being given more information than you need >> and having to decide what bits to ignore and which are important. > > > It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how to > wade tracebacks Hmm, I don't think that's a language reference question. It's more something that I would put into a series of blog posts. But I agree - this is a great topic to discuss. Ultimately, debugging consists of two things: find out more about what's going on, and dig through the data from the first step to figure out what's significant. Tips for helping people master either half of that are well worth publishing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Mon, 4 Jan 2016 02:31 pm, Chris Angelico wrote: > On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: >> On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano >> wrote: >>> But I think it is a real issue. I believe in beautiful tracebacks that >>> give you just the right amount of information, neither too little nor >>> two much. Debugging is hard enough with being given more information >>> than you need and having to decide what bits to ignore and which are >>> important. >> >> >> It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how >> to wade tracebacks > > Hmm, I don't think that's a language reference question. It's more > something that I would put into a series of blog posts. Or the tutorial, like Rustom suggested :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Mon, Jan 4, 2016 at 2:48 PM, Steven D'Aprano wrote: > On Mon, 4 Jan 2016 02:31 pm, Chris Angelico wrote: > >> On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: >>> On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano >>> wrote: But I think it is a real issue. I believe in beautiful tracebacks that give you just the right amount of information, neither too little nor two much. Debugging is hard enough with being given more information than you need and having to decide what bits to ignore and which are important. >>> >>> >>> It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how >>> to wade tracebacks >> >> Hmm, I don't think that's a language reference question. It's more >> something that I would put into a series of blog posts. > > Or the tutorial, like Rustom suggested :-) Not sure it really belongs there; the tutorial tends to keep to short and un-nested pieces of code, where this kind of technique really comes into its own with dozen-line tracebacks. The FAQ could have a link to it, but honestly, the best python.org place I can think of is the wiki. It's not something that has a single straight-forward answer; it's "when you're staring at this much info, here are some ideas for boiling it down to what matters". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
On 01/03/2016 05:51 PM, Random832 wrote: > Just as a general comment, I note there are now at least four mangled > versions of this subject header, and threading is already fragile enough > on this list. I think in the future it would be best to avoid non-ASCII > characters in subject lines. I noticed this too. Though threading based on message-id is working quite well, as designed! -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 9:02:16 AM UTC+5:30, Chris Angelico wrote: > On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: > > On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano > > wrote: > >> But I think it is a real issue. I believe in beautiful tracebacks that give > >> you just the right amount of information, neither too little nor two much. > >> Debugging is hard enough with being given more information than you need > >> and having to decide what bits to ignore and which are important. > > > > > > It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how to > > wade tracebacks > > Hmm, I don't think that's a language reference question. It's more > something that I would put into a series of blog posts. But I agree - > this is a great topic to discuss. Ultimately, debugging consists of > two things: find out more about what's going on, and dig through the > data from the first step to figure out what's significant. Tips for > helping people master either half of that are well worth publishing. Its one of the great paradoxes of programming pedagogy: - Everyone who talks programs by default talks right programs - Everyone who writes programs by default writes wrong programs And if you dont believe that, tell me after having taught programming for 30 odd years :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
Michael Torrie writes: > I noticed this too. Though threading based on message-id is working > quite well, as designed! It doesn't work as well here as elsewhere, though, because message-ids get rewritten by the usenet gateway, so the IDs referenced in people's headers differ depending on whether they're replying via usenet or the mailing list or gmane. Threads already get mangled enough by this even when the subject stays the same. -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > If I could have the traceback continue into the C code and tell me the > line of C code that raised the exception, *that's* what I'd choose. If you are serious about believing this would be a good thing, you can open a ticket on the bug tracker and make an enhancement request that tracebacks generated from builtins should expose their internal details: >>> 7 + [] Traceback (most recent call last): File "", line 1, in File "longobject.c", line 3008, in long_add File "longobject.c", line 1425, in CHECK_BINOP TypeError: unsupported operand type(s) for +: 'int' and 'list' When you open that ticket, be so good as to add me to the Nosy list. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Fri, 1 Jan 2016 09:48 am, Chris Angelico wrote:
> On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney
> wrote:
[...]
>> As best I can tell, Steven is advocating a way to obscure information
>> from the traceback, on the assumption the writer of a library knows that
>> I don't want to see it.
>>
>> Given how very often such decisions make my debugging tasks needlessly
>> difficult, I'm not seeing how that's a desirable feature.
>
> What Steven's actually advocating is removing a difference between
> Python code and native code. Compare:
Well, not quite. What I'm really doing is two-fold:
(1) reminding people that the part of the code which determines the
existence of an error need not be the part of the code which actually calls
raise; and
(2) suggesting a tiny change to the semantics of raise which would make this
idiom easier to use. (Namely, have "raise None" be a no-op.)
I'm saddened but not astonished at just how much opposition there is to
point (1), even though it is something which Python has been capable of
since the earliest 1.x days. Exceptions are first-class objects, and just
because raising an exception immediately after a test is a common idiom:
if condition:
raise SomeError('whatever')
doesn't mean it is *always* the best idiom. I have identified a common
situation in my own code where I believe that there is a better idiom. From
the reaction of others, one might think I've suggested getting rid of
exceptions altogether and replacing them with GOTO :-)
Let's step back a bit and consider what we might do if Python were a less
capable language. We might be *forced* to perform error handling via status
codes, passed from function to function as needed, until we reach the top
level of code and either print the error code or the program's intended
output. None of us want that, but maybe there are cases where a less
extreme version of the same thing is useful. Just because I detect an error
condition in one function doesn't necessarily mean I want to trigger an
exception at that point. Sometimes it is useful to delay raising the
exception.
Suppose I write a validation function that returns a status code, perhaps an
int, or a Enum:
def _validate(arg):
if condition(arg):
return CONDITION_ERROR
elif other_condition(arg):
return OTHER_ERROR
return SUCCESS
def func(x):
status = _validate(x)
if status == CONDITION_ERROR:
raise ConditionError("condition failed")
elif status == OTHER_ERROR:
raise OtherError("other condition failed")
assert status == SUCCESS
...
Don't worry about *why* I want to do this, I have my reasons. Maybe I want
to queue up a whole bunch of exceptions before doing something with them,
or conditionally decide whether or not raise, like unittest. Perhaps I can
do different sorts of processing of different status codes, including
recovery from some:
def func(x):
status = _validate(x)
if status == CONDITION_ERROR:
warnings.warn(msg)
x = massage(x)
status = SUCCESS
elif status == OTHER_ERROR:
raise SomeError("an error occurred")
assert status == SUCCESS
do_the_real_work(x)
There's no reason to say that I *must* raise an exception the instant I see
a problem.
But why am I returning a status code? This is Python, not C or bash, and I
have a much more powerful and richer set of values to work with. I can
return an error type, and an error message:
def _validate(arg):
if condition(arg):
return (ConditionError, "condition failed")
elif other_condition(arg):
return (OtherError, "something broke")
return None
But if we've come this far, why mess about with tuples when we have an
object oriented language with first class exception objects?
def _validate(arg):
if condition(arg):
return ConditionError("condition failed")
elif other_condition(arg):
return OtherError("something broke")
return None
The caller func still decides what to do with the status code, and can
process it when needed. If the error is unrecoverable, it can raise. In
that case, the source of the exception is func, not _validate. Just look at
the source code, it tells you right there where the exception comes from:
def func(x):
exc = _validate(x)
if exc is not None:
raise exc # this is the line you see in the traceback
do_the_real_work(x)
This isn't "hiding information", but it might be *information hiding*, and
it is certainly no worse than this:
def spam():
if condition:
some_long_message = "something ...".format(
many, extra, arguments)
exc = SomeError(some_long_message, data)
raise exc # this is the line you see in the traceback
If I have a lot of functions that use the same exception, I can refactor
them so that building the exception object occurs elsewhere:
def spam():
if condition:
exc = _build_exception()
raise ex
Re: GitHub's ³pull request² is proprietary lock-in
Chris Angelico writes: > On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin wrote: >> Chris Angelico writes: >>> If you're not using a GitHub PR, then what you're doing is using GH to >>> host your repository. >> What's the point of GH in that situation? > Mainly hosting, plus you can use gh-pages and other features. Plenty. GH pages are just normal web pages with markdown processing, right? What other features? And doesn't that come back around to getting locked into the walled garden? -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > If I could have the traceback continue into the C code and tell me the > > line of C code that raised the exception, *that's* what I'd choose. > > If you are serious about believing this would be a good thing, you can open > a ticket on the bug tracker and make an enhancement request that tracebacks > generated from builtins should expose their internal details: > > > >>> 7 + [] > Traceback (most recent call last): > File "", line 1, in > File "longobject.c", line 3008, in long_add > File "longobject.c", line 1425, in CHECK_BINOP > TypeError: unsupported operand type(s) for +: 'int' and 'list' > > > When you open that ticket, be so good as to add me to the Nosy list. Prior Art: An emacs lisp error stops at the boundaries of emacs lisp if I use standard (debian/ubuntu packaged) emacs. OTOH if compiled from source it points to the C source (last I remember trying) -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > If I could have the traceback continue into the C code and tell me the > > line of C code that raised the exception, *that's* what I'd choose. > > If you are serious about believing this would be a good thing, you can open > a ticket on the bug tracker and make an enhancement request that tracebacks > generated from builtins should expose their internal details: > > > >>> 7 + [] > Traceback (most recent call last): > File "", line 1, in > File "longobject.c", line 3008, in long_add > File "longobject.c", line 1425, in CHECK_BINOP > TypeError: unsupported operand type(s) for +: 'int' and 'list' > > > When you open that ticket, be so good as to add me to the Nosy list. Prior Art: An emacs lisp error stops at the boundaries of emacs lisp if I use standard (debian/ubuntu packaged) emacs. OTOH if compiled from source it points to the C source (last I remember trying) -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Mon, 04 Jan 2016 16:19:51 +1100, Steven D'Aprano wrote: > (1) reminding people that the part of the code which determines the > existence of an error need not be the part of the code which actually > calls raise [...] Do chained exceptions scratch your itch? I don't have experience with Python's version of chained exceptions, but I have used them in Java, and it seems to match your use case rather well. Essentially, each conceptual layer in the code effectively abstracts the details of the lower level layer(s), but preserves the details if you're really interested. (I've only been following this discussion partially; if this has been raised (pun intended) before, then just say so. Thanks.) > I'm saddened but not astonished at just how much opposition there is > to point (1) ... I'll echo the sentiment that we're all adults here, and my opinion that if you're reading tracebacks, then you want as much information as possible, even if it seemed irrelevant to the library author at the time. -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 11:42:51 AM UTC+5:30, Dan Sommers wrote: > > I'm saddened but not astonished at just how much opposition there is > > to point (1) ... > > I'll echo the sentiment that we're all adults here, and my opinion that > if you're reading tracebacks, then you want as much information as > possible, even if it seemed irrelevant to the library author at the > time. And I am saddened at how often mediocre Linux system software can throw a traceback at me -- sometimes for things as basic as a missing command-line parameter. Increasingly often a python traceback. I guess most people here are programmers (and adults) but sometimes we want to wear a different hat (I think). Being a vanilla user of your OS is often one such time -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's ³pull request² is proprietary lock-in
Am 04.01.16 um 06:29 schrieb Paul Rubin: Chris Angelico writes: On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin wrote: Chris Angelico writes: If you're not using a GitHub PR, then what you're doing is using GH to host your repository. What's the point of GH in that situation? Mainly hosting, plus you can use gh-pages and other features. Plenty. GH pages are just normal web pages with markdown processing, right? Yes. The processor is freely available (jekyll, written in Ruby). It's usual to put up a local server (jekyl --serve) while updating the pages, befor you publish them, which is done by a git commit/push to the gh-pages branch. What other features? And doesn't that come back around to getting locked into the walled garden? For the pages definitely not. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
Am 31.12.15 um 16:35 schrieb Steven D'Aprano: But I think it is a real issue. I believe in beautiful tracebacks that give you just the right amount of information, neither too little nor two much. Debugging is hard enough with being given more information than you need and having to decide what bits to ignore and which are important. > The principle is that errors should be raised as close to their cause as possible. If I call spam(a, b) and provide bad arguments, the earliest I can possibly detect that is in spam. (Only spam knows what it accepts as arguments.) Any additional levels beyond spam (like _validate) is moving further away: File "spam", line 19, in this File "spam", line 29, in that <--- where the error really lies File "spam", line 39, in other File "spam", line 89, in spam <--- the first place we could detect it File "spam", line 5, in _validate <--- where we actually detect it As a side note, this problem is solved by an enhanced return statement in Tcl. Translating the syntax to Python, it would read something like: def validate(a,b): if a>b: return(SomeError, code=error, level=1) "raise SomeError" would be identical to "return(SomeError, code=error, level=0)". In general you can return codes for continue, break and return to have the upper level act as if continue, break or raise was executed at the point where the function was called. Christian -- https://mail.python.org/mailman/listinfo/python-list
