Re: functools.wraps behaviour
Chris Angelico wrote:
> On Tue, Sep 16, 2014 at 9:15 AM, ISE Development
> wrote:
>> @functools.wraps(func)
>> def wrapper(self):
>> func(self)
>> return wrapper
>>
>> try:
>> k.method(1)
>> except Exception as e:
>> print('exception:',e)
>>
>> The output (Python 3.3) is:
>>
>> Klass.method:
>> k.method > 0x7f2d7c4570d0>>
>> exception: wrapper() takes 1 positional argument but 2 were given
>>
>> The first two lines are as expected, using the name of the decorated
>> function. However, the exception uses the name of the decorating wrapper
>> function.
>
> In your wrapper, you're swallowing all arguments. That means you're
> consciously rejecting them, and passing none on. If you want a wrapper
> to let the wrapped function decide about arguments, try this:
>
> def decorator(func):
> @functools.wraps(func)
> def wrapper(self, *args, **kwargs):
> func(self, args, kwargs)
> return wrapper
>
> With that change, the error message reports that it's method() that's
> rejecting the args.
>
> So yes, I'd say this is a feature; you can either let the wrapped
> function make the decision, or you can have the wrapping function deal
> with args.
>
> ChrisA
Very good point. Hadn't thought about it that way - it makes sense now.
Thanks.
-- isedev
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
Ben Finney wrote: > "Frank Millman" writes: > >> I know there some Git experts on this list, so I hope you don't mind >> me posting this question here. > > I do. There may be experts on parquetry flooring in this forum, but a > topic is not on-topic merely because some people here may know about it. (1) Frank labelled the post [OT] so that people not interested in off-topic posts can filter it. (2) Parquetry flooring has nothing to do with Python programming, while source control is very relevant. Asking questions about revision control is at least as on-topic as asking what editor one should use for Python programming, a question I note you have been known to respond to :-) In my opinion, objecting to Frank's question is not as friendly or helpful a response as I believe we should aim to provide. A more friendly response would have been to suggest that he would likely get better quality answers by elsewhere, but without the editorialising. It's your right to have a different opinion, of course, and you can continue to agitate for a stricter application of on-topic questions, but I just wanted to say I don't fully agree with your position in this matter. Frank, I am not a git expert, and I don't have an answer for your question, sorry. Ben's advice to ask it elsewhere is sound. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
- On Tue, Sep 16, 2014 9:37 AM CEST Steven D'Aprano wrote: >Ben Finney wrote: > >> "Frank Millman" writes: >> >> I know there some Git experts on this list, so I hope you don't mind >> me posting this question here. >> >> I do. There may be experts on parquetry flooring in this forum, but a >> topic is not on-topic merely because some people here may know about it. > >(1) Frank labelled the post [OT] so that people not interested in off-topic >posts can filter it. > >(2) Parquetry flooring has nothing to do with Python programming, while >source control is very relevant. Asking questions about revision control is >at least as on-topic as asking what editor one should use for Python >programming, a question I note you have been known to respond to :-) > >In my opinion, objecting to Frank's question is not as friendly or helpful a >response as I believe we should aim to provide. A more friendly response >would have been to suggest that he would likely get better quality answers >by elsewhere, but without the editorialising. It's your right to have a >different opinion, of course, and you can continue to agitate for a >stricter application of on-topic questions, but I just wanted to say I >don't fully agree with your position in this matter. > >Frank, I am not a git expert, and I don't have an answer for your question, >sorry. Ben's advice to ask it elsewhere is sound. list I entirely agree with Steven. VCS is about good software craftmenship. It is just as on-topic as PEP8 is. Vcs is for code what toothpaste is for teeth. Witout it you get bad breath and code smell :-) Wrt the question: I think you should commit or stash files before switching branches. Also 'add' files to make them known to Git. I always use 'commit -a -m' to automatically stage all changed files. In short your working copy should be clean before switching branches. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
"Frank Millman" : > You are encouraged to make liberal use of 'branches', Personally, I only use forks, IOW, "git clone". I encourage that practice. Then, there is little need for "git checkout". Instead, I just cd to a different directory. Branches and clones are highly analogous processwise; I would go so far as to say that they are redundant. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: > "Frank Millman" : > >> You are encouraged to make liberal use of 'branches', > > Personally, I only use forks, IOW, "git clone". I encourage that > practice. Then, there is little need for "git checkout". Instead, I just > cd to a different directory. > > Branches and clones are highly analogous processwise; I would go so far > as to say that they are redundant. But rather than listening to, shall we say, *strange* advice like this, Frank, you'll do well to pick up a reliable git tutorial, which should explain branches, commits, the working tree, etc, etc, etc. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
- On Tue, Sep 16, 2014 10:29 AM CEST Chris Angelico wrote: >On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: >> "Frank Millman" : >> >> You are encouraged to make liberal use of 'branches', >> >> Personally, I only use forks, IOW, "git clone". I encourage that >> practice. Then, there is little need for "git checkout". Instead, I just >> cd to a different directory. >> >> Branches and clones are highly analogous processwise; I would go so far >> as to say that they are redundant. > >But rather than listening to, shall we say, *strange* advice like >this, Frank, you'll do well to pick up a reliable git tutorial, which >should explain branches, commits, the working tree, etc, etc, etc. list I like "Pragmatic guide to Git". 122 pages, to the point, practical. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
"Chris Angelico" wrote in message news:CAPTjJmr5gh8=1zPjG_KdTmA2QgT_5jj=kh=jyvrfv1atl1e...@mail.gmail.com... > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: >> "Frank Millman" : >> >>> You are encouraged to make liberal use of 'branches', >> >> Personally, I only use forks, IOW, "git clone". I encourage that >> practice. Then, there is little need for "git checkout". Instead, I just >> cd to a different directory. >> >> Branches and clones are highly analogous processwise; I would go so far >> as to say that they are redundant. > > But rather than listening to, shall we say, *strange* advice like > this, Frank, you'll do well to pick up a reliable git tutorial, which > should explain branches, commits, the working tree, etc, etc, etc. > I don't want to turn this into a full-on Git discussion, so briefly - 1. I have read all the 'git' tutorials I can find, but they have not addressed my question. 2. Albert's response 'commit or stash files before switching branches' makes sense, and actually answers my question. 3. I have sympathy for Marko's position of using clones rather than branches. I realise it does not follow the 'git' philosophy, but it does make it more obvious 'where you are', and lessens the chances of shooting yourself in the foot. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: python script monitor
Nah I mean like there is performance issues. It delivers result that I want just mot very conveinetly fast. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
"Albert-Jan Roskam" wrote in message > > > I like "Pragmatic guide to Git". 122 pages, to the point, practical. > Thanks, Albert-Jan. I have started reading it, and it looks useful. Thanks too for your previous response, which was also 'pragmatic and to the point' :-) Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: python script monitor
On Sep 16, 2014 4:17 AM, "Nicholas Cannon" wrote: > > Nah I mean like there is performance issues. It delivers result that I want just mot very conveinetly fast. Take a look at the cProfile module. That's what it's called in Python 2.x. Not sure if it lost its camel case spelling in 3.x or is now called simply "profile." Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: CSV methodology
jayte wrote:
> On Mon, 15 Sep 2014 09:29:02 +0200, Peter Otten <__pete...@web.de> wrote:
>
>>jayte wrote:
>>
>>> Sorry, I neglected to mention the values' significance. The MXP program
>>> uses the "distance estimate" algorithm in its fractal data generation.
>>> The values are thus, for each point in a 1778 x 1000 image:
>>>
>>> Distance, (an extended double)
>>> Iterations, (a 16 bit int)
>>> zc_x,(a 16 bit int)
>>> zc_y (a 16 bit int)
>>>
>>
>>Probably a bit too early in your "Python career",
>
> Absolutely, just thought it would be interesting to start experimenting,
> while learning (plus, can't help but be anxious)
>
>> but you can read raw data
>>with numpy. Something like
>>
>>with open(filename, "rb") as f:
>>a = numpy.fromfile(f, dtype=[
>>("distance", "f16"),
>>("iterations", "i2"),
>>("zc_x", "i2"),
>>("zc_y", "i2"),
>>]).reshape(1778, 1000)
>>
>>might do, assuming "extended double" takes 16 bytes.
>
> Will try. Double extended precision is ten bytes, but I assume
> changing the "f16" to "f10" would account for that...
Unfortunately it seems that numpy doesn't support "f10"
>>> numpy.dtype("f8")
dtype('float64')
>>> numpy.dtype("f16")
dtype('float128')
>>> numpy.dtype("f10")
dtype('float32') # looks strange to me
But you better ask for confirmation (and possible workarounds) in a
specialist forum.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.3.2 help
Hi, Can i be taken off the list please as i am getting too many e-mails. Thank you, David Moorcroft ICT Operations Manager & Website Manager Turves Green Girls' School - Original Message - From: "Steven D'Aprano" To: python-list@python.org Sent: Monday, 15 September, 2014 3:08:09 PM Subject: Re: Python 3.3.2 help Hello David, and thanks for replying. More comments below. D Moorcroft wrote: > Hi, > > We are using windows 7 and it is all pupils as they are more restricted > than staff. > > They are using the python 3.3.2 shell and trying to print from there What you are describing does not sound like the sort of error the Python shell will give. Are you able to copy and paste the student's exact input and output, including the complete error message? If not, can you take a screenshot and post that? (As a general rule, we prefer text-based communication rather than pictures. For all we know, there could be blind or other visually-impaired users on this forum who can read text via a screen reader, but cannot contribute when it is a screenshot. But if all else fails, a screenshot is better than nothing.) We would love to help you, but without further information we have no idea what is going on. The more concrete information you can pass on to us, the better. Regards, Steve > > Thank you, > > David Moorcroft > ICT Operations Manager & > Website Manager > Turves Green Girls' School > > - Original Message - > From: "Steven D'Aprano" > To: python-list@python.org > Sent: Wednesday, 10 September, 2014 1:15:49 PM > Subject: Re: Python 3.3.2 help > > Hello, > > My response is below, interleaved with your comments. > > D Moorcroft wrote: > >>> Hi, >>> >>> We are running Python 3.3.2 but pupils are unable to print as they >>> cannot use the command prompt. > > What operating system are you using? Windows, Linux, Mac? Something else? > > Is it ALL pupils who are unable to print or just some of them? > > Which command prompt are they using? Can you reproduce the failure to > print? If so, please tell us the detailed steps you (and the pupils) go > through. E.g. something like this: > > "On Windows XP, choose Run from the Start Menu. Type cmd.exe and press > Enter. When the terminal window opens, type print 'Hello World' and > Enter." > > It will help if you can tell us whether your pupils are using IDLE, > IPython, or the default Python interactive interpreter. > > If you can answer these questions, which should have a better chance of > diagnosing the problem. > > Further responses below. > > >>> An error comes up saying printing failed (exit status Oxff). > > Based on this, my guess is that your students are accidentally running the > DOS "print" command at the DOS prompt, not Python at all. Perhaps they are > forgetting to run the "python" command first to launch the Python > interpreter, and are running directly in the DOS prompt? > > You can check this by reading the command prompt. If it looks like three > greater-than signs >>> then you are running in Python's default > interpreter. If it looks something like this: > > C:\Documents and Settings\user\> > > or perhaps like this: > > C:\> > > then you are still inside the DOS command prompt. > > Unfortunately, I am not very experienced with Windows, so I cannot tell > you the right method to start Python. I would expect there to be a Start > menu command, perhaps called "IDLE", or "Python", but I'm not sure. > > >>> Is there any way that we can get users who can't see the command >>> prompt to be able to print? > > I'm not entirely sure I understand this question. Can you explain in more > detail? > > By the way, as you know there are two meanings of "print" in computing. > There is printing to the screen, and printing to sheets of paper with an > actual printer. Which are you intending? > > > Regards, > > > -- Steven -- https://mail.python.org/mailman/listinfo/python-list * This message has been checked for viruses by the Birmingham Grid for Learning. For guidance on good e-mail practice, e-mail viruses and hoaxes please visit: http://www.bgfl.org/emailaup * * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@bgfl.org The views expressed within this email are those of the individual, and not necessarily those of the organisation * -- https://mail.python.org/mailman/listinfo/python-list
Re: List insert at index that is well out of range - behaves like append that too SILENTLY
On 2014-09-16 06:58, dieter wrote: Harish Tech writes: Let me demonstrate the problem I encountered : I had a list a = [1, 2, 3] when I did a.insert(100, 100) [1, 2, 3, 100] as list was originally of size 4 and I was trying to insert value at index 100 , it behaved like append instead of throwing any errors as I was trying to insert in an index that did not even existed . Should it not throw IndexError: list assignment index out of range At least the documentation states that what you observe is the intended behaviour. According to the documentation, "a.insert(i, x)" is equivalent to "a[i:i] = x" (i.e. a slice assignment) and if in a slice "a[i:j]" "i" or "j" are larger then "len(a)", then it is replaced by "len(a)". If this is not what you want, derive your own list type and override its "insert" method. It's nice to be able to say a.insert(p, x) even when p == len(a) instead of having a special case: if p == len(a): a.append(x) else: a.insert(p, x) Of course, what to do when p > len(a) is another matter. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.3.2 help
On 2014-09-16 12:25, D Moorcroft wrote: Hi, Can i be taken off the list please as i am getting too many e-mails. [snip] It's up to you to unsubscribe from the list. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
Chris Angelico wrote: > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: >> "Frank Millman" : >> >>> You are encouraged to make liberal use of 'branches', >> >> Personally, I only use forks, IOW, "git clone". I encourage that >> practice. Then, there is little need for "git checkout". Instead, I just >> cd to a different directory. >> >> Branches and clones are highly analogous processwise; I would go so far >> as to say that they are redundant. > > But rather than listening to, shall we say, *strange* advice like > this, Frank, you'll do well to pick up a reliable git tutorial, which > should explain branches, commits, the working tree, etc, etc, etc. Isn't this "strange advice" standard operating procedure in Mercurial? I'm not an expert on either hg or git, but if I've understood hg correctly, the way to begin an experimental branch is to use hg clone. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On Tue, Sep 16, 2014 at 10:14 PM, Steven D'Aprano wrote: > Chris Angelico wrote: > >> On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: >>> "Frank Millman" : >>> You are encouraged to make liberal use of 'branches', >>> >>> Personally, I only use forks, IOW, "git clone". I encourage that >>> practice. Then, there is little need for "git checkout". Instead, I just >>> cd to a different directory. >>> >>> Branches and clones are highly analogous processwise; I would go so far >>> as to say that they are redundant. >> >> But rather than listening to, shall we say, *strange* advice like >> this, Frank, you'll do well to pick up a reliable git tutorial, which >> should explain branches, commits, the working tree, etc, etc, etc. > > Isn't this "strange advice" standard operating procedure in Mercurial? I'm > not an expert on either hg or git, but if I've understood hg correctly, the > way to begin an experimental branch is to use hg clone. I don't know Mercurial well enough to be able to say, but definitely branching is a very normal thing there, too. And since merging can be done only within a single repo, ultimately you need to end up with branches in one repo (rather than separate repos) if you're going to combine them in any way. So even if you do start some experimental work in a separate clone, you're probably going to need to end up with it as a separate branch in the same repo if you ever publish it, for instance. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On 16 September 2014 22:14, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > Chris Angelico wrote: > > > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa > wrote: > >> "Frank Millman" : > >> > >>> You are encouraged to make liberal use of 'branches', > >> > >> Personally, I only use forks, IOW, "git clone". I encourage that > >> practice. Then, there is little need for "git checkout". Instead, I just > >> cd to a different directory. > >> > >> Branches and clones are highly analogous processwise; I would go so far > >> as to say that they are redundant. > > > > But rather than listening to, shall we say, *strange* advice like > > this, Frank, you'll do well to pick up a reliable git tutorial, which > > should explain branches, commits, the working tree, etc, etc, etc. > > Isn't this "strange advice" standard operating procedure in Mercurial? I'm > not an expert on either hg or git, but if I've understood hg correctly, the > way to begin an experimental branch is to use hg clone. It depends entirely on how you're comfortable working. I tend to have a clone per feature branch (they all push to the same central repo) and then create a named branch per task (which may be a prototype, bugfix, enhancement, whatever). Makes it very easy to switch between tasks - I just update to a different changeset (normally the tip of a named branch) and force a refresh in my IDE. When I'm happy, I merge into the feature branch, then pull the necessary changesets into other feature branch repos to merge/graft as appropriate. Branches and clones are two different ways of organising, and I find that things work best for me when I use both. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On Tue, 2014-09-16 at 10:59 +0200, Frank Millman wrote: > "Chris Angelico" wrote in message > news:CAPTjJmr5gh8=1zPjG_KdTmA2QgT_5jj=kh=jyvrfv1atl1e...@mail.gmail.com... > > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: > >> "Frank Millman" : > >> > >>> You are encouraged to make liberal use of 'branches', > >> > >> Personally, I only use forks, IOW, "git clone". I encourage that > >> practice. Then, there is little need for "git checkout". Instead, I just > >> cd to a different directory. > >> > >> Branches and clones are highly analogous processwise; I would go so far > >> as to say that they are redundant. > > > > But rather than listening to, shall we say, *strange* advice like > > this, Frank, you'll do well to pick up a reliable git tutorial, which > > should explain branches, commits, the working tree, etc, etc, etc. > > > > I don't want to turn this into a full-on Git discussion, so briefly - > > 1. I have read all the 'git' tutorials I can find, but they have not > addressed my question. > 2. Albert's response 'commit or stash files before switching branches' makes > sense, and actually answers my question. > 3. I have sympathy for Marko's position of using clones rather than > branches. I realise it does not follow the 'git' philosophy, but it does > make it more obvious 'where you are', and lessens the chances of shooting > yourself in the foot. I'm with Chris on this one. I use git extensively (I manage more than just software with it -- I used it as version tracking when I was working on my dissertation, articles I'm writing, script databases, project management, etc.) One of the code git repos I work with every day is ~4 GB for a working repo and ~1.6 GB for a bare one. At any given time, I have ~6 branches I'm working on. To have a separate repo for each branch is madness (especially on a SSD where storage is expensive). A trick I use to avoid ever getting lost inside my git repository is to set up my command-line prompt so it always displays the active branch [1]: swails@batman ~/amber (master) $ git branch amber12-with-patches amber13-with-patches amber14-with-patches amoeba2 amoeba2_diis * master sander-python yorkmaster swails@batman ~/amber (master) $ git checkout sander-python Switched to branch 'sander-python' Your branch is up-to-date with 'origin/sander-python'. swails@batman ~/amber (sander-python) $ Doing everything as branches in the same repository has a number of other advantages as well. Merges don't have to be preceded by a fetch (e.g., a git-pull). You can cherry-pick individual commits between branches. You only have one copy of the git objects. You can use "git diff" or "git difftool" to directly compare specific files or folders between branches or different revisions in diverged history between branches. I wouldn't expect you to know all of this git-magic from the outset, but you will learn it as you need to. Assigning each branch to a new clone severely limits git's capabilities. [2] All the best, Jason [1] See http://jswails.wikidot.com/using-git#toc48 for details of how to do this [2] Technically this isn't true since each repository will know about the branches of the other repositories it pulls from, but cherry-picking, merging, diffing, etc. between a branch and a remote copy of a branch on the same machine is a lot more convoluted than working with everything in the same repo (that and you never accidentally look at an outdated version of a 'local' branch because you forgot to fetch or pull!) -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-ID - how much could be?
Am 11.09.2014 23:32 schrieb Ervin Hegedüs: There is no upper limit to the thread name other than that you will eventually run out of memory ;) thanks - I hope that the memory will not run out by these threads... :) Anyway, that means, on my system: import sys print sys.maxint 9223372036854775807 the couter could be 9223372036854775807? And after? :) After that, the couter magically turns into a long and it goes on. Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: Iterator, modify data in loop body
Am 13.09.2014 09:22 schrieb Chris Angelico: In that case, don't iterate over the list at all. Do something like this: while lst: element = lst.pop(0) # work with element lst.append(new_element) And if you don't like that, define a def iter_pop(lst): while lst: yield lst.pop(0) and you can do for element in iter_pop(lst): # work with element lst.append(new_element) Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: Iterator, modify data in loop body
On Tue, Sep 16, 2014 at 6:49 PM, Thomas Rachel wrote: > Am 13.09.2014 09:22 schrieb Chris Angelico: > >> In that case, don't iterate over the list at all. Do something like this: >> >> while lst: >> element = lst.pop(0) >> # work with element >> lst.append(new_element) > > > And if you don't like that, define a > > def iter_pop(lst): > while lst: > yield lst.pop(0) > > and you can do > > for element in iter_pop(lst): But that's exactly the same thing, with another level of indirection. It certainly isn't the advantage you'd expect from an iterator, namely that it simply stores a marker that gets advanced to the next element. Popping the 0th element is costly, wrapping it into an iterator conceals that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On 2014-09-16 13:14, Steven D'Aprano wrote: Chris Angelico wrote: On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa wrote: "Frank Millman" : You are encouraged to make liberal use of 'branches', Personally, I only use forks, IOW, "git clone". I encourage that practice. Then, there is little need for "git checkout". Instead, I just cd to a different directory. Branches and clones are highly analogous processwise; I would go so far as to say that they are redundant. But rather than listening to, shall we say, *strange* advice like this, Frank, you'll do well to pick up a reliable git tutorial, which should explain branches, commits, the working tree, etc, etc, etc. Isn't this "strange advice" standard operating procedure in Mercurial? I'm not an expert on either hg or git, but if I've understood hg correctly, the way to begin an experimental branch is to use hg clone. Yes, but this is due to different design decisions of git and Mercurial. git prioritized the multiple branches in a single clone use case; Mercurial prioritized re-cloning. It's natural to do this kind of branching in git, and more natural to re-clone in Mercurial. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern wrote: > Yes, but this is due to different design decisions of git and Mercurial. git > prioritized the multiple branches in a single clone use case; Mercurial > prioritized re-cloning. It's natural to do this kind of branching in git, > and more natural to re-clone in Mercurial. Ah, I wasn't aware of that philosophical difference. Does hg use hardlinks or something to minimize disk usage when you clone, or does it actually copy everything? (Or worse, does it make the new directory actually depend on the old one?) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On 9/16/2014 4:00 AM, Albert-Jan Roskam wrote On Tue, Sep 16, 2014 9:37 AM CEST Steven D'Aprano wrote: Ben Finney wrote: "Frank Millman" writes: I know there some Git experts on this list, so I hope you don't mind me posting this question here I do. There may be experts on parquetry flooring in this forum, but a topic is not on-topic merely because some people here may know about it. I agree. If a post on parquet flooring were held for moderation, I would discard it. Threads that wander off into parquet flooring type topics are best let die. (1) Frank labelled the post [OT] so that people not interested in off-topic posts can filter it. (2) Parquetry flooring has nothing to do with Python programming, while source control is very relevant. Asking questions about revision control is at least as on-topic as asking what editor one should use for Python programming, The proper parallel is revision control for Python versus editor for Python. Since Frank is a known Python user, I presume 'for Python' was part of his question. Revision control for word processing would be a bit far afield for this list. a question I note you have been known to respond to :-) git, in particular, is used for both development *of* CPython and development *with* Python. At least one of the git sites has a clone of the cpython hg repository that some have used to develop patches. On the core-mentorship list, there has also been discussion about git branching and how it differs from hg use. I entirely agree with Steven. VCS is about good software craftmenship. > It is just as on-topic as PEP8 is. I think that is too strong, but Frank did not claim that either. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Too many emails, remove (was Re: Python 3.3.2 help)
On 9/16/2014 7:25 AM, D Moorcroft wrote: Can i be taken off the list please as i am getting too many e-mails. Go to https://mail.python.org/mailman/listinfo/python-list and at the bottom, enter your email address in the box after "To unsubscribe from Python-list, get a password reminder, or change your subscription options enter your subscription email address: " One can selectively read python-list as a newsgroup at news.gmane.org either through the web interface or by 'subscribing' in a news reader. Most modern email programs, such as Thunderbird, include a news reader. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On 2014-09-16 17:25, Chris Angelico wrote: On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern wrote: Yes, but this is due to different design decisions of git and Mercurial. git prioritized the multiple branches in a single clone use case; Mercurial prioritized re-cloning. It's natural to do this kind of branching in git, and more natural to re-clone in Mercurial. Ah, I wasn't aware of that philosophical difference. Does hg use hardlinks or something to minimize disk usage when you clone, or does it actually copy everything? (Or worse, does it make the new directory actually depend on the old one?) I haven't kept up with the internals recently, but at least at one point, hardlinks were the order of the day, yes. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
Terry Reedy writes: > I agree. If a post on parquet flooring were held for moderation, I > would discard it. Threads that wander off into parquet flooring type > topics are best let die. I'm glad to know that, thank you. > >> (2) Parquetry flooring has nothing to do with Python programming, > >> while source control is very relevant. Asking questions about > >> revision control is at least as on-topic as asking what editor one > >> should use for Python programming, > > The proper parallel is revision control for Python versus editor for > Python. Right. I'd consider “how do I use Emacs?” to be inappropriate here, and would want the question directed to a more appropriate forum. When it's “how do I use Emacs to correctly indent Python code?” the question is appropriate here. I'm of the opinion the original question was of the first, inappropriate, kind. > Since Frank is a known Python user, I presume 'for Python' was > part of his question. Revision control for word processing would be a > bit far afield for this list. I didn't see a good reason to think the question had any particular relevance to Python programming (no more than, say, “how do I use Emacs correctly?”) and responded on that basis. I acknowledge that's a judgement call, made by a participant with no special power here. There is an infinite number of topics we could discuss, and would likely be of interest to many people here. Just because some individuals may be found to talk about a topic doesn't make this forum appropriate for that discussion. That was the explicit reason given for a question acknowledged to be off-topic, and *that's* why I responded firmly: the reason given is invalid. The usefulness of a particular forum is only maintained by maintaining the common explicit topic of interest as the criterion, and redirecting most topics away. -- \ “I believe our future depends powerfully on how well we | `\ understand this cosmos, in which we float like a mote of dust | _o__) in the morning sky.” —Carl Sagan, _Cosmos_, 1980 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Problems in python pandas
Hi All,
I am having some problem in python.
I have written the code
import pandas as pd
import numpy as np
from scipy.optimize import minimize
pd.set_option('display.mpl_style', 'default')
"""Read the input file into the dataframe""" """T1 file contains the decision
variables, corresponding investments and their upper and lower bounds"""
df = pd.DataFrame.from_csv('C:\Users\prashant.mudgal\Downloads\T1.csv')
"""T2 file contains the parameters for the decision variables, note that there
can be 2 or more entries for the same decison variable""" """ Our objective
func will be prep from T2 file , it will be of the form sum (all DV in params
file) (a*(b + c * DV_name)** power) """
df2 = pd.DataFrame.from_csv('C:\Users\prashant.mudgal\Downloads\T2.csv')
"""subset of DV"""
decisionVars= df2['DV']
"""subset for coeff """
coeff = df2['coef']
"""subset for power"""
power = df2['p']
x0 = df['Hist_Inv']
bnds = df[['LB','UB']].values
def objFunc(decisionVars,sign=1.0) :
return sign*(sum(coeff.values[0:] *(df2['weight_f'].values[0:] +
df2['weight_v'].values[0:] * decisionVars[0:])**power.values[0:]))
"""bounds for the decision variables have been hardcoded """ """ The bounds
have been hardcoded and it will be cumbersome if there are thousands of
Decision vars """ """ The bounds have been specified in T1.csv file, we want to
ream them via the file """
""" Though we are not using constraints as of now, but is it correct form"""
""" How to form the constraints for say x + y < 5 ? """ cons = ({'type':
'ineq', 'fun': lambda x: decisionVars[1] - 2 * decisionVars[1] + 2}, {'type':
'ineq', 'fun': lambda x: -decisionVars[2] - 2 * decisionVars[1] + 6}, {'type':
'ineq', 'fun': lambda x: -decisionVars[0] + 2 * decisionVars[1] + 2})
""" the second parameter is the initial values that needs to be optimized"""
""" Now, the number of distinct decision vars in the files are 3 in numbers
while the total number of decision vars are 12 in number . if we specify x0 as
the dataframe of investment (3 in number in the T1 file) , then it gives error
that ::: operands could not be broadcast together with shapes (12,) (3,)"""
res = minimize(objFunc, x0,args=(-1.0,),method='SLSQP',bounds = bnds,
options={'disp': True})
"""Print the results"""
print (res)
T1.csv is like DV LB UB Hist_Inv X1 0.7 1.3 28462739.43 X2 0.7 1.3 177407.18 X3
0.7 1.3 1423271.12
T2.csv is
Count DV weight_fweight_vp coef
1 X1 2.310281831 3.661156016 0.5 1828.105881
2 X1 0.693084549 2.20503016 0.5 1460.686147
3 X1 0.207925365 2.030522789 0.5 1436.277144
4 X1 0 5.248353307 0.8 1050.493355
5 X1 0 1.591805116 0.8 983.9964128
6 X1 0 1.933056056 0.8 459.9371809
7 X2 7.322516444 138 0.5 387.4659072
8 X2 3.661258222 139 0.5 606.8684771
9 X2 1.830629111 176.5 0.5 358.8902965
10 X3 164294.4758 77024 0.2 282.0477107
11 X3 98576.68545 122261.40.2 345.9217482
12 X3 59146.01127 166242.84 0.2 364.9587162
I create my obj function using vars in T2, there are a lot of vars which are
repeated in T2.csv on running optimization I am getting the error operands
could not be broadcast together with shapes (12,) (3,) because it is taking all
the variables in T2 as different. How should I avoid this issue? X1, X2 AND X3
are the only three vars here.
Please help. I am stuck for past many days on this.
Thanks,
Prashant Mudgal
AI (Accenture Interactive)
+1 917 615 3574(Cell)
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise confidential information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the e-mail by you is prohibited. Where allowed by local law, electronic
communications with Accenture and its affiliates, including e-mail and instant
messaging (including content), may be scanned by our systems for the purposes
of information security and assessment of internal compliance with Accenture
policy.
__
www.accenture.com
--
https://mail.python.org/mailman/listinfo/python-list
Why `divmod(float('inf'), 1) == (float('nan'), float('nan'))`
While debugging my code I found that the bug was because I assumed that
something like `divmod(float('inf'), 1)` would be equal to `(float('inf'),
float('nan'))`, while Python returns `(float('nan'), float('nan'))`. Why does
Python make the division result be NaN in this case? `float('inf') / 1` is
still `float('inf')`.
Thanks,
Ram.
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
Jason Swails : > One of the code git repos I work with every day is ~4 GB for a working > repo and ~1.6 GB for a bare one. At any given time, I have ~6 branches > I'm working on. Well, branches could be seen as a compression technique. I'm trying to keep my git repositories in the < 1 MB range. Marko -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Jedi Python Autocomplete in Zeus IDE
The latest version of the Zeus IDE adds Python autocomplete using the Jedi package. Details about Jedi can be found here: http://jedi.jedidjah.ch/en/latest/ Details of how the autocomplete works can be found here: http://www.zeusedit.com/zforum/viewtopic.php?t=7200 Details of whats new in this latest Zeus release can be found here: http://www.zeusedit.com/ze397u.html *NOTE:* Zeus is shareware, runs natively on the Windows platform and runs on Linux using Wine. Jussi Jumppanen Author: Zeus IDE -- https://mail.python.org/mailman/listinfo/python-list
Re: Why `divmod(float('inf'), 1) == (float('nan'), float('nan'))`
On 9/16/2014 5:40 PM, cool-RR wrote:
While debugging my code I found that the bug was because I assumed
that something like `divmod(float('inf'), 1)` would be equal to
`(float('inf'), float('nan'))`, while Python returns `(float('nan'),
float('nan'))`. Why does Python make the division result be NaN in
this case? `float('inf') / 1` is still `float('inf')`.
For integers, divmod(x, y) is defined as (x // y, x % y) == ((x - x%y)
// y, x % y) == ((x - x%y) / y, x % y).
For floats, Python is documented as using the third expression.
"Help on built-in function divmod in module builtins:
divmod(...)
divmod(x, y) -> (div, mod)
Return the tuple ((x-x%y)/y, x%y). Invariant: div*y + mod == x."
It does not really matter, however, as infinity cannot be 'floored' as
required for //
>>> math.floor(float('inf'))
Traceback (most recent call last):
File "", line 1, in
math.floor(float('inf'))
OverflowError: cannot convert float infinity to integer
and hence
>>> float('inf') // 1.0
nan
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Question about Git branches
On 17 September 2014 02:25, Chris Angelico wrote: > On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern > wrote: > > Yes, but this is due to different design decisions of git and Mercurial. > git > > prioritized the multiple branches in a single clone use case; Mercurial > > prioritized re-cloning. It's natural to do this kind of branching in git, > > and more natural to re-clone in Mercurial. > I disagree that it's more natural to re-clone in Mercurial. It's just that the preferred workflow of the Mercurial developers is to use clones, anonymous branches and bookmarks (almost the same as git branches) rather than named branches - and so that is the workflow that is most associated with using Mercurial. Mercurial fully supports multiple lines of development by: 1. cloning; 2. anonymous branching (i.e. multiple heads on the same branch) - normally combined with bookmarks; 3. named branching (the branch name is an integral part of the commit); 4. all of the above combined. Eventually if you want to merge between lines of development then you end up with multiple branches (either anonymous or named) in the one repo. > Ah, I wasn't aware of that philosophical difference. Does hg use > hardlinks or something to minimize disk usage when you clone, or does > it actually copy everything? (Or worse, does it make the new directory > actually depend on the old one?) > If you clone a repo to the same filesystem (e.g. the same disk partition) then Mercurial will use hardlinks for the repository files (i.e. things in .hg). This means that clones are quick (although if you don't prevent updating the working directory while cloning that can take some time ...). Hardlinks may be broken any time changesets are added to the repo e.g. via a commit or pull. Only the hardlinks involved in the commit (and the manifest) will be broken. Mercurial provides a standard extension (relink) to re-establish hardlinks between identical storage files. For example, running hg relink in my current feature branch repo: [feature_branch_repo:65179] [feature_branch]> hg relink default relinking d:\home\repos\feature_branch_repo\.hg/store to d:\home\repos\default_repo\.hg/store tip has 22680 files, estimated total number of files: 34020 collected 229184 candidate storage files pruned down to 49838 probably relinkable files relinked 359 files (221 MB reclaimed) Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
the python shell window is already executing a command
I have googled for a solution to this problem. None I have tried worked. I have a very short program that runs for a count of 20 and ends. What I do is click on the IDLE window and without making any changes I just hit f5 to rerun the program. Sometimes I get the error "the python shell window is already executing a command" and sometimes not. I am using XP and Python 3.4.1. Is there a way to rerun a program without getting this error? -- https://mail.python.org/mailman/listinfo/python-list
