Re: We will be moving to GitHub
W dniu 03.01.2016 o 01:33, Marko Rauhamaa pisze: > Teamware didn't have to pick any of them since Teamware's commits were > done per individual files. The repository didn't have a commit history. > > Thus, Teamware was equivalent to Hg/Git with each file treated as an > independent repository. > It sounds like CVS. How can you be sure that your code is consistent if each of your file has it's own, independent history? Use tags like in CVS? r. m. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
W dniu 03.01.2016 o 05:43, Ben Finney pisze: > 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. I'm also afraid that Github will make to git the same thing as Google did to Jabber/XMPP. Decade ago, I had plenty of friends on my jabber contacts list. Next, Google made it's talk compatible with jabber, then my friends slowly migrated to gtalk, because if they used gmail anyway, then why not use it also for jabber? And then Google turned off XMPP support and suddenly I lost ability to contact with 80% of my friends without having stupid hangouts running, or without falling back to email (which is not so bad BTW). The same can be with Github and git. PPL will forget how to use git without github. When Github will make git-incompatible changes, vast majority will need/want to follow the changes and eg. will use Gitlabs propertiary binary. r. m. -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
m :
> W dniu 03.01.2016 o 01:33, Marko Rauhamaa pisze:
>> Teamware didn't have to pick any of them since Teamware's commits were
>> done per individual files. The repository didn't have a commit history.
>>
>> Thus, Teamware was equivalent to Hg/Git with each file treated as an
>> independent repository.
>>
>
> It sounds like CVS.
The main problem with CVS is that these operations don't commute:
*
edit :
+--+--->
\ \ :
\ \ :
\branch\merge:
\ \:
v v :
+--+-->
:
:
:
:
+---+-->
\ ^ :
\/:
\branch/merge:
\/ :
v edit / :
+-+--->
:
If you look at the edited file at *, CVS reveals the merge direction in
the version history. In Teamware, you can't see afterwards, which way
the change was made ("branches" and "merges" are not recorded).
Additionally, CVS doesn't make the distinction between commits and
merges, which both Hg/Git and Teamware do. The distinction could be
emulated in CVS (as well as, say, Perforce) but very awkwardly.
> How can you be sure that your code is consistent if each of your file
> has it's own, independent history? Use tags like in CVS?
Yes, tags ("checkpoints") can be used, although I don't remember us
using them. Rather, we used distinct clones for tagging.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 11:23:24 AM UTC+5:30, Rustom Mody wrote: > 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) I think I mis-remembered this: It is not tracebacks but docs that reach from front-facing lisp (commands) through internal lisp (functions) to C in elisp. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
On 01/04/2016 03:21 AM, m wrote: > W dniu 03.01.2016 o 05:43, Ben Finney pisze: >> 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. > > I'm also afraid that Github will make to git the same thing as Google > did to Jabber/XMPP. > > Decade ago, I had plenty of friends on my jabber contacts list. Next, > Google made it's talk compatible with jabber, then my friends slowly > migrated to gtalk, because if they used gmail anyway, then why not use > it also for jabber? > > And then Google turned off XMPP support and suddenly I lost ability to > contact with 80% of my friends without having stupid hangouts running, > or without falling back to email (which is not so bad BTW). I use gtalk with Pidgin every day using XMPP. So Google still supports XMPP. However what they stopped doing was allowing federated XMPP, which pretty much breaks XMPP, at least the spirit of it. So the only way to chat with gtalk users is to use your gtalk account. But you certainly don't need hangouts. XMPP works fine between your client and the Google server. I agree that Google really pulled a bad one with gtalk though. Dropping federated XMPP support was definitely not in keeping with their original "do no evil" mantra. > The same can be with Github and git. PPL will forget how to use git > without github. When Github will make git-incompatible changes, vast > majority will need/want to follow the changes and eg. will use Gitlabs > propertiary binary. Yup you are correct. However for the foreseeable future, you can still do a git clone from github, and you can still use your local repository normally. In fact I think this is really part of the github workflow. But who knows what the future will bring. I can sure see the wisdom of the GPLv3 as we move into a world of software as a service, where even Microsoft uses Linux, and charges us for it. -- https://mail.python.org/mailman/listinfo/python-list
What is the fastest way to do 400 HTTP requests using requests library?
So what is the fastest way to make 400 HTTP requests using "requests" library and also using tor proxy? Best regards -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's "pull request" is proprietary lock-in
On Monday, January 4, 2016 at 12:41:32 PM UTC-5, Michael Torrie wrote: > On 01/04/2016 03:21 AM, m wrote: > > W dniu 03.01.2016 o 05:43, Ben Finney pisze: > >> 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. > > > > I'm also afraid that Github will make to git the same thing as Google > > did to Jabber/XMPP. > > > > Decade ago, I had plenty of friends on my jabber contacts list. Next, > > Google made it's talk compatible with jabber, then my friends slowly > > migrated to gtalk, because if they used gmail anyway, then why not use > > it also for jabber? > > > > And then Google turned off XMPP support and suddenly I lost ability to > > contact with 80% of my friends without having stupid hangouts running, > > or without falling back to email (which is not so bad BTW). > > I use gtalk with Pidgin every day using XMPP. So Google still supports > XMPP. However what they stopped doing was allowing federated XMPP, > which pretty much breaks XMPP, at least the spirit of it. So the only > way to chat with gtalk users is to use your gtalk account. But you > certainly don't need hangouts. XMPP works fine between your client and > the Google server. > > I agree that Google really pulled a bad one with gtalk though. Dropping > federated XMPP support was definitely not in keeping with their original > "do no evil" mantra. > > > The same can be with Github and git. PPL will forget how to use git > > without github. When Github will make git-incompatible changes, vast > > majority will need/want to follow the changes and eg. will use Gitlabs > > propertiary binary. > > Yup you are correct. However for the foreseeable future, you can still > do a git clone from github, and you can still use your local repository > normally. In fact I think this is really part of the github workflow. > But who knows what the future will bring. I can sure see the wisdom of > the GPLv3 as we move into a world of software as a service, where even > Microsoft uses Linux, and charges us for it. about: > PPL will forget how to use git without github. We cannot forget what we never learned. git is way to complicated for regular users without support like what github provides. I haven't done a merge without the Green Button in a long time. And when I did I always had to triple check to make sure to avoid any mistakes. I never needed to check what a pull request would be in pure git. Josef -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Marko Rauhamaa wrote: > Well, Git and Mercurial are not all that bad as long as only a single > person is working on the repository at any given time and you have a > strictly linear version history. I cannot confirm your observations(?) for Git. There was a time when three of four people of our team (me included) were working in the same and in different branches of the same repository without any serious problem (occasional merge conflicts cannot be avoided in such a scenario, of course). The resulting commit tree was fascinating to us :) Also, that Git appears to work well with Linux kernel development (for which it was created) where probably hundreds of developers, if not more, are working on at the same time, casts into doubt the correctness of your statement, and the amount of your work experience with Git. > That would be advisable anyway as you should have a separate repository > for each conceptual unit. Apples and oranges. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the fastest way to do 400 HTTP requests using requests library?
On Tue, 5 Jan 2016 07:50 am, livems...@gmail.com wrote: > So what is the fastest way to make 400 HTTP requests using "requests" > library and also using tor proxy? Since this will be I/O bound, not CPU bound, probably use separate threads. Push the 400 requests into a queue, then create N threads, where N will need to be determined by experiment, but will probably be something like 4 or 8, and let each thread pop a request from the queue as needed. Are you experienced with threads? Do you need further information about using threads and queues? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the fastest way to do 400 HTTP requests using requests library?
On Mon, Jan 4, 2016 at 4:38 PM, Steven D'Aprano wrote: > On Tue, 5 Jan 2016 07:50 am, livems...@gmail.com wrote: > >> So what is the fastest way to make 400 HTTP requests using "requests" >> library and also using tor proxy? > > > Since this will be I/O bound, not CPU bound, probably use separate threads. > > Push the 400 requests into a queue, then create N threads, where N will need > to be determined by experiment, but will probably be something like 4 or 8, > and let each thread pop a request from the queue as needed. > > Are you experienced with threads? Do you need further information about > using threads and queues? Also see the concurrent.futures module in the standard library, which makes this sort of setup very simple to implement. -- https://mail.python.org/mailman/listinfo/python-list
Re: GitHub's “pull request” is proprietary lock-in
W dniu 04.01.2016 o 18:41, Michael Torrie pisze: >> Decade ago, I had plenty of friends on my jabber contacts list. Next, >> > Google made it's talk compatible with jabber, then my friends slowly >> > migrated to gtalk, because if they used gmail anyway, then why not use >> > it also for jabber? >> > >> > And then Google turned off XMPP support and suddenly I lost ability to >> > contact with 80% of my friends without having stupid hangouts running, >> > or without falling back to email (which is not so bad BTW). > I use gtalk with Pidgin every day using XMPP. So Google still supports > XMPP. However what they stopped doing was allowing federated XMPP, > which pretty much breaks XMPP, at least the spirit of it. So the only > way to chat with gtalk users is to use your gtalk account. Exactly. My friends slowly migrated to using gtalk instead of jabber client, because if they have open gmail anyways, then why should they bother with installing additional software. 80% never came back to jabber client. They don't need to, they still have communication between them and I'm minority which uses strange not supported technology :). > But you > certainly don't need hangouts. XMPP works fine between your client and > the Google server. Oh, and it's definitively what I want - talk with google server ;). > > I agree that Google really pulled a bad one with gtalk though. Dropping > federated XMPP support was definitely not in keeping with their original > "do no evil" mantra. > >> > The same can be with Github and git. PPL will forget how to use git >> > without github. When Github will make git-incompatible changes, vast >> > majority will need/want to follow the changes and eg. will use Gitlabs >> > propertiary binary. > Yup you are correct. However for the foreseeable future, you can still > do a git clone from github, and you can still use your local repository > normally. And I can do nothing with it, because nobody will want to cooperate with me - they will use github instead of git. Sad thing is that it's rather inevitable and not moving python repo to github or not won't stop the process. However - wise would be to have github-like software on own servers. p. m. -- https://mail.python.org/mailman/listinfo/python-list
Is there a way importing a string object?
For example, name = "test" # test.py is a module's file import name Regards, Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a way importing a string object?
On Mon, Jan 4, 2016 at 5:49 PM, wrote: > For example, > > name = "test" # test.py is a module's file > import name Yes, use the importlib.import_module function. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a way importing a string object?
jf...@ms4.hinet.net writes: > For example, (Please make the body of your message complete. The “Subject” field should be a summary of your message's subject, and may not be read as the first line of your message.) > name = "test" # test.py is a module's file > import name The standard library ‘importlib’ module exports an API for the import machinery https://docs.python.org/3/library/importlib.html>. You will likely want to use ‘importlib.import_module’ https://docs.python.org/3/library/importlib.html#importlib.import_module>. -- \ “The difference between a moral man and a man of honor is that | `\ the latter regrets a discreditable act, even when it has worked | _o__) and he has not been caught.” —Henry L. Mencken | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Is '*args' useful in this example code?
Hi, I find an example code on wrap at this link: http://stackoverflow.com/questions/308999/what-does-functools-wraps-do Here is the code: def logged(func): def with_logging(*args, **kwargs): print func.__name__ + " was called" return func(*args, **kwargs) return with_logging /// I understand now, but I feel the args usage is weird. I don't see any way to use *args and **kwargs in above code. What is your opinion on it? Thanks, -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a way importing a string object?
jf...@ms4.hinet.net at 2016/1/5 UTC+8 8:49:56AM wrote: Thanks, Ian and Ben. This forum is really a good place for learning Python. I am glad I had join in. To Ben, > (Please make the body of your message complete. The "Subject" field > should be a summary of your message's subject, and may not be read as > the first line of your message.) Yes, The "Subject" seems a little strange, read likes a part of the body. I am bad on composition. Even after your reminder, I still can't think of a better one:-( -- https://mail.python.org/mailman/listinfo/python-list
Re: Is '*args' useful in this example code?
Robert writes: > I understand now, but I feel the args usage is weird. I don't see any way > to use *args and **kwargs in above code. What is your opinion on it? Can you show example code that you would expect, and specifically what about the actual code doesn't match what you expect? -- \“Of course, everybody says they're for peace. Hitler was for | `\ peace. Everybody is for peace. The question is: what kind of | _o__)peace?” —Noam Chomsky, 1984-05-14 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Is '*args' useful in this example code?
On Monday, January 4, 2016 at 9:26:47 PM UTC-5, Ben Finney wrote: > Robert writes: > > > I understand now, but I feel the args usage is weird. I don't see any way > > to use *args and **kwargs in above code. What is your opinion on it? > > Can you show example code that you would expect, and specifically what about > the actual code doesn't match what you expect? > > -- > \"Of course, everybody says they're for peace. Hitler was for | > `\ peace. Everybody is for peace. The question is: what kind of | > _o__)peace?" --Noam Chomsky, 1984-05-14 | > Ben Finney Excuse me for the incomplete info previously. If I call it with a = f(3) the result is 12. It is correct as below message. That is no use of *args and **kwargs. If I put more parameters in f, it will give errors as below. /// %run "C:/Users/pyprj/ipython0/decor0.py" f was called --- TypeError Traceback (most recent call last) C:\Users\pyprj\ipython0\decor0.py in () 11return x + x * x 12 ---> 13 a = f(3, 4) 14 C:\Users\pyprj\ipython0\decor0.py in with_logging(*args, **kwargs) 3 def with_logging(*args, **kwargs): 4 print func.__name__ + " was called" > 5 return func(*args, **kwargs) 6 return with_logging 7 TypeError: f() takes exactly 1 argument (2 given) %run "C:/Users/rj/pyprj/ipython0/decor0.py" f was called a Out[13]: 12 /// I don't see *args and **kwargs can be used by other way yet. Do you think this internal function definition (with *args) is useful? Thanks, -- https://mail.python.org/mailman/listinfo/python-list
Re: Is '*args' useful in this example code?
Robert writes: > On Monday, January 4, 2016 at 9:26:47 PM UTC-5, Ben Finney wrote: > > Can you show example code that you would expect, and specifically what about > > the actual code doesn't match what you expect? > > Excuse me for the incomplete info previously. > If I call it with > a = f(3) > the result is 12. Can you show a *very* simple example of the ‘f’ you're talking about? Contrive a new one, make it behave the same way while keeping it very short, and once you have that, put that code in your message. With an actual function to examine it will be much easier to know where the confusion lies. -- \ “When a well-packaged web of lies has been sold to the masses | `\over generations, the truth will seem utterly preposterous and | _o__)its speaker a raving lunatic.” —Dresden James | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Is '*args' useful in this example code?
On 01/04/2016 09:16 PM, Robert wrote: Hi, I find an example code on wrap at this link: http://stackoverflow.com/questions/308999/what-does-functools-wraps-do Here is the code: def logged(func): def with_logging(*args, **kwargs): print func.__name__ + " was called" return func(*args, **kwargs) return with_logging /// I understand now, but I feel the args usage is weird. I don't see any way to use *args and **kwargs in above code. What is your opinion on it? The reason the inner method has *args, and **kwargs as parameters is so that it doesn't have to exactly match the signature of func. If func was a method that took 3 parameters, then if you didn't use *args, you would have to define the with_logging method to also take 3 parameters. If func takes one or more keyword parameters, then you would have to add that to the definition of the with_logging method if you don't use **kwargs. IOW, using *args and **kwargs in the wrapper method definition removes the requirement that its parameter list exactly match func's parameter list. -- https://mail.python.org/mailman/listinfo/python-list
Re: Need help - How to identify the cell display format?
I tried the following,
from openpyxl.reader.excel import load_workbook
book = load_workbook(filename='transactions.xlsx')
sheet = book.get_sheet_by_name('transactions')
print sheet.cell("A12").style.number_format
print sheet.cell("A13").style.number_format
But there is some problem with the load_workbook package. I get a error in
reading .xls file.
Could anyone please help me out from this?
Its really Urgent for me, Is there any other alternative way to read excel
cell display format?
--
Warm regards,
Ezhilarasan
On Tue, Dec 15, 2015 at 7:34 PM, Larry Martell
wrote:
> On Tue, Dec 15, 2015 at 2:29 AM, Ezhilarasan Chandrasekar
> wrote:
> > Hi folks,
> >
> > I just want to find the cell display format in Excel. I have a Expected
> > excel file and Actual Excel file.
> >
> > I have some knowledge about, how to check the cell value, cell font,
> > alignment. But I also want to know about what type of cell format is
> being
> > used.
> >
> > For example: If the cell value has "*04:05:00 AM*", but it displays as "
> > *04:05:00*"(AM notation not needed) which is of format "*hh:mm:ss*"
> >
> > I want to identify the cell format *(hh:mm:ss)* from Expected Excel file
> > and compare with the Actual Excel file
>
> You can do this with openpyxl, for example:
>
> from openpyxl.reader.excel import load_workbook
>
> book = load_workbook(filename='transactions.xlsx')
> sheet = book.get_sheet_by_name('transactions')
> print sheet.cell("A12").style.number_format
> print sheet.cell("A13").style.number_format
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Where are we in the Python 3 transition?
I switched to Python 3 between three and four years ago, I think. I was actually eager to make the switch, as I could see the value of clean Unicode support and lazy evaluation. I had to wait until Matplotlib supported Py3, then I changed. -- https://mail.python.org/mailman/listinfo/python-list
