Re: We will be moving to GitHub
On Sat, Jan 2, 2016 at 5:43 PM, Steven D'Aprano wrote: > On Sat, 2 Jan 2016 07:09 am, Chris Angelico wrote: > >> Yes, git is a capable tool. But so is Mercurial, and the arguments >> weren't primarily based on differences in functionality (which are >> pretty minor). It's mainly about the network effect. > > You call it the network effect. I call it monoculture. The "you" here is the generic "you" rather than specifically addressing me; I'm merely citing the discussions already given. I'm going to assume that everyone here has read PEP 481, so if you haven't, please go read it before responding. https://www.python.org/dev/peps/pep-0481/ > This decision is socially irresponsible. For all the cheap talk about > diversity, the Python core-devs are now about to move to (and probably give > money to) a company with a well-deserved reputation of being hostile to > women. Even if you believe that Github has reformed (and I see no credible > evidence that they have, apart from Github's own self-serving statements > that they have), diversity doesn't just apply to human individuals, it also > applies to technologies. The fact that Github is so popular should count > *against* it, not in favour. If that is an argument, then it's one to push people to GitLab over GitHub, but nothing about git vs hg. > There are times where everybody should do the same thing -- choosing whether > to drive on the left or the right side of the road, for example. And there > are times where following the crowd like lemmings is actively harmful, no > matter how convenient it seems in the short-run. The popularity of technology IS an argument in its favour, though. How many people here use Gopher instead of HTTP? Would it be better to serve Python content on the obscure protocol rather than the popular one? When 99% of people know how to use one technology and 1% know how to use a different one, it's advantageous to go where the people are. (Of course, there are other considerations, too - PHP is popular, but that alone isn't a reason to use it. The context here is of technologies so similar in functionality that we really CAN make a decision on these kinds of bases.) The Python project *needs* new contributors. This is not in question. You can't expect to keep the project going solely on the basis of the people currently writing and applying patches. So there are two options: 1) Do everything using a workflow peculiar to Python, using a less-popular technology 2) Put everything on a massively-popular web site using the more popular technology, and do everything exactly the way everyone else does. Yes, the latter might be the lemming approach. But do we actually have a problem with git and a pull-request workflow? (Concerns about GitHub as a company are a separate consideration. As mentioned above, GitLab is a similar option, and would allow python.org to host its own instance if desired.) I have worked one-on-one with about 70 students over the past two years, introducing them to Python and web development, and using git and GitHub for their projects. They can now go on to contribute to any of a huge number of projects. If, instead, we'd taught them to use Mercurial, they still wouldn't be able to immediately contribute to CPython, because the workflow is custom. (You don't actually create a commit, you just use 'hg diff >patchfile' and upload that. And if you're actually a core contributor, you need to be careful about where you merge things, and which direction.) Moving CPython to GitHub would mean anyone could simply fork it on the server and push a commit, then paste a link into bugs.python.org and let someone decide to merge it. So which would you prefer? Arbitrary technological diversity, or a large pool of potential contributors? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Terry Reedy writes: > On 1/1/2016 4:08 PM, Zachary Ware wrote: > > There were three reasons given in Brett's decision message: > > > > 1. No major distinguishing features between GitHub or GitLab It seems “complete source code available and freely licensed, allowing the community to implement the entire tool set elsewhere, without any need to consult the existing service provider” – i.e. community control over their own tools – is not considered a major distinguishing feature. > In particular, some inactive contributors who use git and github > apparently emailed Brett to say that they might re-activate if they > could use the process they otherwise use all the time instead of > Python's idiosyncratic workflow. This is a grave concern. A strong implication of “use the process they otherwise use all the time” is that these people expect to use GitHub's proprietary, centralised, single-vendor workflow tools. This implication necessarily entails rejecting contributions from other community members who don't use those single-vendor tools. The decision to take tools that were expressly designed to escape single-vendor centralisation, and then willingly build single-vendor workflows around them which divide the free software community along vendor lines, is a foolish and worrying trend. I am alarmed to see the Python core team go further down that path. -- \ “… whoever claims any right that he is unwilling to accord to | `\ his fellow-men is dishonest and infamous.” —Robert G. | _o__) Ingersoll, _The Liberty of Man, Woman and Child_, 1877 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Zachary Ware writes: > On Jan 1, 2016 2:35 PM, "Paul Rubin" wrote: > > Will everyone wanting to submit patches be required to use a Github > > account? Or will it be enough to put the patch in an outside repo > > and link to it in the Python issue tracker? I'm glad that (it sounds > > like) no Github account will be needed to submit bug reports. > > Correct, no GitHub account will be required for interactions on the > bugs.python.org tracker, and a patch can move all the way through to > commit entirely on the b.p.o tracker (just as currently). My experience with contributing to repositories hosted on GitHub, from repositories hosted elsewhere, necessitates the question: What is being done to stave off the common response, addressed by GitHub users to people submitting a change as a link to their Git repository, of “can you please submit that as a GitHub pull request”? That common response makes for an unnecessary and IMO unacceptable pressure toward centralisation. GitHub's “pull request” workflow is entirely proprietary and can only be done within GitHub. What will be done to ensure other Git repositories remain on a level playing field not only technically, but socially? -- \ “Ours is a world where people don't know what they want and are | `\ willing to go through hell to get it.” —Donald Robert Perry | _o__) Marquis | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On Sat, 2 Jan 2016 07:09 am, Chris Angelico wrote: > Yes, git is a capable tool. But so is Mercurial, and the arguments > weren't primarily based on differences in functionality (which are > pretty minor). It's mainly about the network effect. You call it the network effect. I call it monoculture. This decision is socially irresponsible. For all the cheap talk about diversity, the Python core-devs are now about to move to (and probably give money to) a company with a well-deserved reputation of being hostile to women. Even if you believe that Github has reformed (and I see no credible evidence that they have, apart from Github's own self-serving statements that they have), diversity doesn't just apply to human individuals, it also applies to technologies. The fact that Github is so popular should count *against* it, not in favour. There are times where everybody should do the same thing -- choosing whether to drive on the left or the right side of the road, for example. And there are times where following the crowd like lemmings is actively harmful, no matter how convenient it seems in the short-run. http://nedbatchelder.com/blog/201405/github_monoculture.html Oh, and talking about DVCS: https://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Terry Reedy writes: > While the decision might not be my personal first choice, we > absolutely need more core developers contributing, including reviewing > contributed patches. Yeah, I'm not delighted by the choice either, but as long as the core devs have bought in and it doesn't affect non-core devs (occasional contributors and bug reporters), then whatever. FWIW, Scaleway has a 1-click (well, several clicks) Gitlab installer: https://www.scaleway.com/imagehub/gitlab/ It launches a 3 euro/month ARM dedicated server and deploys Gitlab on it. I haven't used Gitlab yet but have been using Gogs (gogs.io) a little. It's a lighter-weight Github-like thing written in Go, that however is still missing some important features like pull requests. I like it though. It runs nicely on cheap VPS where Gitlab is a resource hog. -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On 1/1/2016 4:08 PM, Zachary Ware wrote: On Fri, Jan 1, 2016 at 2:03 PM, wrote: Is there a summary document that discusses the options examined and why others did not meet the requirements? I am -NOT- trying to dredge up arguments about the choice. I am guessing that there have been some. Easiest would be to look through the archives of the core-workflow mailing list: https://mail.python.org/pipermail/core-workflow/ In particular: https://mail.python.org/pipermail/core-workflow/2016-January/000345.html . If this fact-based decision was based solely on the fact that the BDFL prefers GitHub, please just say so. It is clear that git is a capable tool. There were three reasons given in Brett's decision message: 1. No major distinguishing features between GitHub or GitLab Note that GitHub and GitLab were the only proposals under consideration; nobody else stepped up to champion any other solution. 2. Familiarity amongst core devs -- and external contributors -- with GitHub In particular, some inactive contributors who use git and github apparently emailed Brett to say that they might re-activate if they could use the process they otherwise use all the time instead of Python's idiosyncratic workflow. While the decision might not be my personal first choice, we absolutely need more core developers contributing, including reviewing contributed patches. 3. Guido prefers GitHub Guido repeatedly stated that his preference should not be taken into account. I believe Brett gave it little weight, but obviously it was in his mind. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Need help on a project To :"Create a class called BankAccount with the following parameters "
On Saturday, December 12, 2015 at 10:05:29 AM UTC+1, Harbey Leke wrote:
> Create a class called BankAccount
>
> .Create a constructor that takes in an integer and assigns this to a
> `balance` property.
>
> .Create a method called `deposit` that takes in cash deposit amount and
> updates the balance accordingly.
>
> .Create a method called `withdraw` that takes in cash withdrawal amount and
> updates the balance accordingly. if amount is greater than balance return
> `"invalid transaction"`
>
> .Create a subclass MinimumBalanceAccount of the BankAccount class
>
> Please i need help on this i am a beginer into python programming.
>
>
> Also below is a test case given for this project
>
>
> import unittest
> class AccountBalanceTestCases(unittest.TestCase):
> def setUp(self):
> self.my_account = BankAccount(90)
>
> def test_balance(self):
> self.assertEqual(self.my_account.balance, 90, msg='Account Balance
> Invalid')
>
> def test_deposit(self):
> self.my_account.deposit(90)
> self.assertEqual(self.my_account.balance, 180, msg='Deposit method
> inaccurate')
>
> def test_withdraw(self):
> self.my_account.withdraw(40)
> self.assertEqual(self.my_account.balance, 50, msg='Withdraw method
> inaccurate')
>
> def test_invalid_operation(self):
> self.assertEqual(self.my_account.withdraw(1000), "invalid transaction",
> msg='Invalid transaction')
>
> def test_sub_class(self):
> self.assertTrue(issubclass(MinimumBalanceAccount, BankAccount), msg='No
> true subclass of BankAccount')
Thank God for this group, its a very helpful. It turns out i had a correct code
all the while. i found out that the "line 23 test" failed because of the case
sensitivity.
i used - return ("Invalid Transaction")
instead of
return ("invalid transaction")
Notice the "i" and "t"
Thanks again
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need help on a project To :"Create a class called BankAccount with the following parameters "
On Saturday, December 26, 2015 at 12:06:07 AM UTC+1, Won Chang wrote: > i have gotten the answer of that problem Please Can you post the answer you got. If convenient send to my email xaviertim...@gmail.com. Thanks in advance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid Python tricks
On 31.12.15 05:51, Steven D'Aprano wrote: Fifteen years later, and Tim Peters' Stupid Python Trick is still the undisputed champion! It may be platform depended, but on my computer the obvious way is 10% faster the Stupid Python Trick. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Data Analysis Recommendations
On 1/1/16 1:24 PM, Mark Lawrence wrote: > On 31/12/2015 17:15, Rob Gaddi wrote: >> I'm looking for some advice on handling data collection/analysis in >> Python. ... >> The whole process feels a bit grindy; like I keep having to do a lot of >> ad-hoc stitching things together. And I keep hearing about pandas, >> PyTables, and HDF5. Would that be making my life notably easier? If >> so, does anyone have any references on it that they've found >> particularly useful? The tutorials I've seen so far seem to not give >> much detail on what the point of what they're doing is; it's all "how >> you write the code" rather than "why you write the code". Paying money >> for books is acceptable; this is all on the company's time/dime. >> >> Thanks, >> Rob Cyrille Rossant's books may meet your needs. The Interactive Computing and Visualization Cookbook offers more than just recipes. As the topics get advanced, he explains the whys in addition to the hows. It may not have specific answers to parameter sweep experiments but I understood more about Python's internals and packages as they related to my work. It helped me to refine when to use Python and when to use other languages. Currently US $5 via the publisher: https://www.packtpub.com/books/info/authors/cyrille-rossant (I have no affiliation with the author or publisher) Mark Lawrence writes: > I don't understand your comment about tutorials. Once they've given you > an introduction to the tool, isn't it your responsibility to manipulate > your data in the way that suits you? If you can't do that, either > you're doing something wrong, or the tool is inadequate for the task. > For the latter I believe you've two options, find another tool or write > your own. Without second-guessing the OP, I've found Python tutorials and documents to be helpful but not always complete in a way that beginners and casual users would need. There is usually a package that will do some job but one first has to find it. A lot of power can also be located deep within a hierarchy of dots: package.something.subsomething.subsubsomething ... Some documentation sets are very complete, others aren't. I often have the nagging feeling that if I just knew what question to ask and knew the right terminology, that I could benefit from code someone has already written and/or develop a smarter plan of attack. Ravi Narasimhan http://www.rettacs.org -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid Python tricks
On 01.01.16 21:00, paul.hermeneu...@gmail.com wrote: On Wed, Dec 30, 2015 at 11:09 PM, Steven D'Aprano wrote: On Thu, 31 Dec 2015 04:02 pm, Rick Johnson wrote: Fifteen years later, and Tim Peters' Stupid Python Trick is still the undisputed champion! And should we be happy about that revelation, or sad? Yes! Which one, Steve? Happy or sad? True. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Data Analysis Recommendations
On 31/12/2015 17:15, Rob Gaddi wrote: I'm looking for some advice on handling data collection/analysis in Python. I do a lot of big, time consuming experiments in which I run a long data collection (a day or a weekend) in which I sweep a bunch of variables, then come back offline and try to cut the data into something that makes sense. For example, my last data collection looked (neglecting all the actual equipment control code in each loop) like: for t in temperatures: for r in voltage_ranges: for v in test_voltages[r]: for c in channels: for n in range(100): record_data() I've been using Sqlite (through peewee) as the data backend, setting up a couple tables with a basically hierarchical relationship, and then handling analysis with a rough cut of SQL queries against the original data, Numpy/Scipy for further refinement, and Matplotlib to actually do the visualization. For example, one graph was "How does the slope of straight line fit between measured and applied voltage vary as a function of temperature on each channel?" The whole process feels a bit grindy; like I keep having to do a lot of ad-hoc stitching things together. And I keep hearing about pandas, PyTables, and HDF5. Would that be making my life notably easier? If so, does anyone have any references on it that they've found particularly useful? The tutorials I've seen so far seem to not give much detail on what the point of what they're doing is; it's all "how you write the code" rather than "why you write the code". Paying money for books is acceptable; this is all on the company's time/dime. Thanks, Rob I'd start with pandas http://pandas.pydata.org/and see how you get on. If and only if pandas isn't adequate, and I think that highly unlikely, try PyTables. Quoting from http://www.pytables.org/ "PyTables is a package for managing hierarchical datasets and designed to efficiently and easily cope with extremely large amounts of data." and "PyTables is built on top of the HDF5 library". I've no idea what the definition of "extremely large" is in this case. How much data are you dealing with? I don't understand your comment about tutorials. Once they've given you an introduction to the tool, isn't it your responsibility to manipulate your data in the way that suits you? If you can't do that, either you're doing something wrong, or the tool is inadequate for the task. For the latter I believe you've two options, find another tool or write your own. I would not buy books, on the simple grounds that they go out of date far faster then the online docs :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Zachary Ware writes: > Correct, no GitHub account will be required for interactions on the > bugs.python.org tracker, and a patch can move all the way through to commit > entirely on the b.p.o tracker (just as currently). Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On Fri, Jan 1, 2016 at 2:03 PM, wrote: > Is there a summary document that discusses the options examined and why > others did not meet the requirements? I am -NOT- trying to dredge up > arguments about the choice. I am guessing that there have been some. Easiest would be to look through the archives of the core-workflow mailing list: https://mail.python.org/pipermail/core-workflow/ > If this fact-based decision was based solely on the fact that the BDFL > prefers GitHub, please just say so. It is clear that git is a capable tool. There were three reasons given in Brett's decision message: 1. No major distinguishing features between GitHub or GitLab Note that GitHub and GitLab were the only proposals under consideration; nobody else stepped up to champion any other solution. 2. Familiarity amongst core devs -- and external contributors -- with GitHub 3. Guido prefers GitHub Guido repeatedly stated that his preference should not be taken into account. I believe Brett gave it little weight, but obviously it was in his mind. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On 01/01/2016 20:03, paul.hermeneu...@gmail.com wrote: Mark, it is good to know that a decision has been made so that we can move forward. Is there a summary document that discusses the options examined and why others did not meet the requirements? I am -NOT- trying to dredge up arguments about the choice. I am guessing that there have been some. If this fact-based decision was based solely on the fact that the BDFL prefers GitHub, please just say so. It is clear that git is a capable tool. There is no point in targetting any queries at me, I'm just the messenger :) I've loosly followed the discussion on the core workflow mailing list, but frankly much of that said goes right over my head, as my knowledge of GitHub, GitLab, Mercurial and all the rest of them is roughly zero. There is all ready disagreement over the decision. I'll sit back and let the core developers sort that out, confident that eventually we'll end up with working processes backed up by working systems. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On Jan 1, 2016 2:35 PM, "Paul Rubin" wrote: > > Zachary Ware writes: > > ... the canonical CPython repository will be moving to GitHub in the > > near future. Note that we will *not* be using the GitHub issue > > tracker or wiki, just the hosting and review/pull request system. > > Will everyone wanting to submit patches be required to use a Github > account? Or will it be enough to put the patch in an outside repo and > link to it in the Python issue tracker? I'm glad that (it sounds like) > no Github account will be needed to submit bug reports. Correct, no GitHub account will be required for interactions on the bugs.python.org tracker, and a patch can move all the way through to commit entirely on the b.p.o tracker (just as currently). -- Zach (On a phone) -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Zachary Ware writes: > ... the canonical CPython repository will be moving to GitHub in the > near future. Note that we will *not* be using the GitHub issue > tracker or wiki, just the hosting and review/pull request system. Will everyone wanting to submit patches be required to use a Github account? Or will it be enough to put the patch in an outside repo and link to it in the Python issue tracker? I'm glad that (it sounds like) no Github account will be needed to submit bug reports. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python.Exe Problem
Daniel, after the download, please be sure to verify the MD5 checksum to know that the download is correct. On Tue, Dec 29, 2015 at 1:44 PM, Terry Reedy wrote: > On 12/29/2015 11:24 AM, Daniel Lee wrote: > >> Hello, >> >> When I try to run python.exe on my computer with Windows 8, >> > > Which exact version? From what source? How did you download (from where) > or compile? How did you install? How do you try to run it? > > I get the following error: >> >> "Python.exe - Entry Point Not Found" >> >> "The Procedure entry point ?terminate@@YAXXZ could not be located in the >> dynamic link library C:\Program Files\Python3.5\python.exe." >> > > Google return 76000 hits for 'terminate@@YAXXZ', so this appears to not > be a unique issue in some form or another. > > What does this error mean and how can I fix it? >> > > It seems like your installed python.exe is corrupt. Make sure you have a > final release. I would re-install, possibly after re-downloading from > python.org. If you download from anywhere else, *they* are responsible > for getting the compile options correct. > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On Sat, Jan 2, 2016 at 6:58 AM, Zachary Ware wrote: >> It's not entirely clear whether that message is an acceptance of PEP 481 > or not. > > I've lost track of the pep numbers, but Brett's decision is final; the > canonical CPython repository will be moving to GitHub in the near future. > Note that we will *not* be using the GitHub issue tracker or wiki, just the > hosting and review/pull request system. There are still several details to > be worked out, though. Okay, so that means it broadly is an acceptance of PEP 481. Hopefully someone who's been involved in the discussions can check over the PEP text and adjust as necessary to make it accurate to what's going to happen. On Sat, Jan 2, 2016 at 7:03 AM, wrote: > Mark, it is good to know that a decision has been made so that we can move > forward. > > Is there a summary document that discusses the options examined and why > others did not meet the requirements? I am -NOT- trying to dredge up > arguments about the choice. I am guessing that there have been some. > > If this fact-based decision was based solely on the fact that the BDFL > prefers GitHub, please just say so. It is clear that git is a capable tool. That's what the PEP is for. Here's the link: https://www.python.org/dev/peps/pep-0481/ Yes, git is a capable tool. But so is Mercurial, and the arguments weren't primarily based on differences in functionality (which are pretty minor). It's mainly about the network effect. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
Mark, it is good to know that a decision has been made so that we can move forward. Is there a summary document that discusses the options examined and why others did not meet the requirements? I am -NOT- trying to dredge up arguments about the choice. I am guessing that there have been some. If this fact-based decision was based solely on the fact that the BDFL prefers GitHub, please just say so. It is clear that git is a capable tool. -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On Jan 1, 2016 1:47 PM, "Chris Angelico" wrote: > > On Sat, Jan 2, 2016 at 6:39 AM, Mark Lawrence wrote: > > Please see > > https://mail.python.org/pipermail/core-workflow/2016-January/000345.html > > > > This should encourage developers at all levels to help out, such that the > > list of open issues on the bug tracker falls drastically. > > How does that interact with the still-Draft status of PEP 481? The > email seems to mainly be saying "not GitLab", but until PEP 481 is > accepted, I'm not certain that GitHub is accepted either. > > It's not entirely clear whether that message is an acceptance of PEP 481 or not. I've lost track of the pep numbers, but Brett's decision is final; the canonical CPython repository will be moving to GitHub in the near future. Note that we will *not* be using the GitHub issue tracker or wiki, just the hosting and review/pull request system. There are still several details to be worked out, though. -- Zach (On a phone) -- https://mail.python.org/mailman/listinfo/python-list
Re: We will be moving to GitHub
On Sat, Jan 2, 2016 at 6:39 AM, Mark Lawrence wrote: > Please see > https://mail.python.org/pipermail/core-workflow/2016-January/000345.html > > This should encourage developers at all levels to help out, such that the > list of open issues on the bug tracker falls drastically. How does that interact with the still-Draft status of PEP 481? The email seems to mainly be saying "not GitLab", but until PEP 481 is accepted, I'm not certain that GitHub is accepted either. It's not entirely clear whether that message is an acceptance of PEP 481 or not. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
We will be moving to GitHub
Please see https://mail.python.org/pipermail/core-workflow/2016-January/000345.html This should encourage developers at all levels to help out, such that the list of open issues on the bug tracker falls drastically. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Example for Multiple and Multilevel Inheritance
On 01/01/2016 19:16, PythonLearner wrote: Hello All, I'm new to this group. I'm looking for examples for Multiple and Multilevel Inheritance without the use of super(). Thanks An Avid Python Learner Please tell us what you're trying to achive, as without super() you'll be throwing DRY right out of the window. You might like to read this, noting especially the first line "If you aren’t wowed by Python’s super() builtin, chances are you don’t really know what it is capable of doing or how to use it effectively.". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Example for Multiple and Multilevel Inheritance
Hello All, I'm new to this group. I'm looking for examples for Multiple and Multilevel Inheritance without the use of super(). Thanks An Avid Python Learner -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid Python tricks
On Wed, Dec 30, 2015 at 11:09 PM, Steven D'Aprano wrote: > On Thu, 31 Dec 2015 04:02 pm, Rick Johnson wrote: > > >> Fifteen years later, and Tim Peters' Stupid Python Trick is still the > >> undisputed champion! > > > > And should we be happy about that revelation, or sad? > > Yes! > > Which one, Steve? Happy or sad? -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac Question
> On Jan 1, 2016, at 5:56 AM, tdspe...@gmail.com wrote: > > Hi All > > I am trying to create a directory on a windows drive from my macbook air with > python but get a permissions error because the windows ntfs drive is read > only - does anyone know away to overcome this issue - I have looked for a > utility but have yet to find an answer. > > Regards and Happy New Year > > Colin > > -- > https://mail.python.org/mailman/listinfo/python-list OS-X can read NTFS drives, but by default cannot write to them, hence the read-only mount. If you have control over that external drive you can format it (on OS-X) as ExFAT, and it can then be written to and read from by both OS-X and Windows. If the drive must be formatted NTFS, you can turn on writing via terminal commands (which works ONLY on a volume-by-volume basis) or using a third party utility. There is a pretty good summary here: http://www.cnet.com/news/how-to-manually-enable-ntfs-read-and-write-in-os-x/ -Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac Question
On Fri, Jan 1, 2016 at 10:27 PM, wrote: > I connect to a drive in a windows 10 computer smb://192.168.50.58/c from my > mac but the drive is read only - i am looking for away to make the drive > writable so I can make a directory on the drive from my python script. > You'll have to look into the permissions setup on both the Windows computer and the Mac. Try connecting from a different computer to that server, or from that Mac to a different server, and see what's going on. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac Question
On Friday, January 1, 2016 at 7:13:41 PM UTC+8, Chris Angelico wrote: > On Fri, Jan 1, 2016 at 9:56 PM, wrote: > > Hi All > > > > I am trying to create a directory on a windows drive from my macbook air > > with python but get a permissions error because the windows ntfs drive is > > read only - does anyone know away to overcome this issue - I have looked > > for a utility but have yet to find an answer. > > > > This isn't a Python question - it's a Windows question. I'll help as > best I can, but you might find better results elsewhere. > > Is this a drive you've mounted across a network, or is it something > local to your computer? Is it a hard drive, a Flash drive (USB stick), > or some other device? > > What are the mount options? (Typing 'mount' in a terminal might tell > you this.) Who owns the files and directories? Can you create stuff on > there using 'sudo'? > > ChrisA Hi ChrisA I know it is not a python issue - I just thought some other python programmers might have come across the problem. I connect to a drive in a windows 10 computer smb://192.168.50.58/c from my mac but the drive is read only - i am looking for away to make the drive writable so I can make a directory on the drive from my python script. Regards Colin -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac Question
On Fri, Jan 1, 2016 at 9:56 PM, wrote: > Hi All > > I am trying to create a directory on a windows drive from my macbook air with > python but get a permissions error because the windows ntfs drive is read > only - does anyone know away to overcome this issue - I have looked for a > utility but have yet to find an answer. > This isn't a Python question - it's a Windows question. I'll help as best I can, but you might find better results elsewhere. Is this a drive you've mounted across a network, or is it something local to your computer? Is it a hard drive, a Flash drive (USB stick), or some other device? What are the mount options? (Typing 'mount' in a terminal might tell you this.) Who owns the files and directories? Can you create stuff on there using 'sudo'? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Mac Question
Hi All I am trying to create a directory on a windows drive from my macbook air with python but get a permissions error because the windows ntfs drive is read only - does anyone know away to overcome this issue - I have looked for a utility but have yet to find an answer. Regards and Happy New Year Colin -- https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
On 01/01/2016 00:25, Mark Lawrence wrote:
On 31/12/2015 18:54, Karim wrote:
On 31/12/2015 19:18, otaksoftspamt...@gmail.com wrote:
I need to check a string over which I have no control for the first 2
non-white space characters (which should be '[{').
The string would ideally be: '[{...' but could also be something like
' [ { '.
Best to use re and how? Something else?
Use pyparsing it is straight forward:
>>> from pyparsing import Suppress, restOfLine
>>> mystring = Suppress('[') + Suppress('{') + restOfLine
>>> result = mystring.parse(' [ { I am learning pyparsing' )
>>> print result.asList()
[' I am learning pyparsing']
You'll get your string inside the list.
Hope this help see pyparsing doc for in depth study.
Karim
Congratulations for writing up one of the most overengineered pile of
cobblers I've ever seen.
You welcome !
The intent was to make a simple introduction to pyparsing which is a
powerful tool for more complex parser build.
Karim
--
https://mail.python.org/mailman/listinfo/python-list
Re: Newbie: Check first two non-whitespace characters
otaksoftspamt...@gmail.com writes:
> I need to check a string over which I have no control for the first 2
> non-white space characters (which should be '[{').
>
> The string would ideally be: '[{...' but could also be something like
> ' [ { '.
>
> Best to use re and how? Something else?
No comment on whether re is good for your use case but another comment
on how. First, some test data:
>>> data = '\r\n {\r\n\t[ "etc" ]}\n\n\n')
Then the actual comment - there's a special regex type, \S, to match a
non-whitespace character, and a method to produce matches on demand:
>>> black = re.compile(r'\S')
>>> matches = re.finditer(black, data)
Then the demonstration. This accesses the first, then second, then third
match:
>>> empty = re.match('', '')
>>> next(matches, empty).group()
'{'
>>> next(matches, empty).group()
'['
>>> next(matches, empty).group()
'"'
The empty match object provides an appropriate .group() when there is no
first or second (and so on) non-whitespace character in the data:
>>> matches = re.finditer(black, '\r\t\n')
>>> next(matches, empty).group()
''
>>> next(matches, empty).group()
''
--
https://mail.python.org/mailman/listinfo/python-list
Re: Converting py files to .exe and .dmg
> On 2016-01-01, at 07:43, Brian Simms wrote: > > when I go into Terminal to run "setup.py install" I keep getting "-bash: > command not found". Try: python setup.py install Greetings, -- https://mail.python.org/mailman/listinfo/python-list
