Re: Issues encountered while launching the IDLE of python 3.7 64-bit I downloaded recently.
On 11/24/2017 6:39 PM, STEPHINEXT TUTORIALS wrote: On Wed, Nov 22, 2017 at 4:29 AM, STEPHINEXT TUTORIALS < oladejist...@gmail.com> wrote: I just downloaded the new version 3.7 for my windows operating system 64-bits on your site. Does Python itself run? The error I got while launching the IDLE How did you try to launch IDLE? is shown in the attached Picture. Python-list (and hence the gmane newsgroup mirror) is a no-attachment list. So the picture was detached. Copy and paste the text if you can or re-type the contents of a Windows error box. I installed all the options I don't know what this means. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does asyncio.wait_for() need a timeout?
"Ian Kelly" wrote in message
news:calwzidmrpfrr5mrejjyz+bdgtqlwy-sp+a_zc6zq7ebaz9g...@mail.gmail.com...
On Fri, Nov 24, 2017 at 6:31 AM, Frank Millman wrote:
> "Frank Millman" wrote in message news:ov5v3s$bv7$1...@blaine.gmane.org...
>
>> Below is a simple asyncio loop that runs two background tasks.
>>
> [...]
>>
>>
>> Both take an optional timeout.
>>
>> If I use the first method without a timeout, the cancellation completes
>> and the loop stops.
>>
>> If I use the second method without a timeout, the future is cancelled,
>> but
>> the program hangs.
>>
>> If I add a timeout to the second one, it behaves the same as the first
>> one.
>>
>> Is there a reason for this?
>>
>
> I have figured out half of the answer.
>
> 'timeout' is an optional argument when using wait(), but a required one
> when
> using wait_for().
>
> Therefore asyncio is raising an exception.
>
> However, I do not understand why no traceback appears.
Here's the output I get when I try it and then interrupt with Ctrl-C:
$ python3 test.py
From 1: 1
From 2: 1
From 1: 2
From 2: 2
From 1: 3
From 2: 3
From 1: 4
From 2: 4
From 1: 5
From 2: 5
From 1: 6
counter1 cancelled
^CTraceback (most recent call last):
File "test.py", line 27, in
loop.run_forever()
File "/usr/lib/python3.5/asyncio/base_events.py", line 345, in
run_forever
self._run_once()
File "/usr/lib/python3.5/asyncio/base_events.py", line 1276, in
_run_once
event_list = self._selector.select(timeout)
File "/usr/lib/python3.5/selectors.py", line 441, in select
fd_event_list = self._epoll.poll(timeout, max_ev)
KeyboardInterrupt
Task exception was never retrieved
future:
exception=TypeError("wait_for() missing 1 required positional
argument: 'timeout'",)>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "test.py", line 20, in counter2
await asyncio.wait_for(cnt1) # hangs
TypeError: wait_for() missing 1 required positional argument: 'timeout'
The unhandled exception is shown as a warning when the loop exits. It
can't be shown prior to that because there could be some other task,
even one that hasn't been scheduled yet, that might try to get the
result of the counter2 task and handle the exception.
Thanks, Ian. All is clear now.
I was testing on Windows. I have never got Ctrl-C to work on Windows, so I
use Ctrl-Pause, which crashes the interpreter and returns immediately,
without showing any pending tracebacks.
I have now tested my program on Linux, and I get the same result as you.
Frank
--
https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Fri, Nov 24, 2017 at 7:05 PM, wrote:
> On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote:
>
>> Since you did not start with tests or write tests as you wrote code, ...
>
> why on earth would you assume that? instantiate "window" and you'll see it
> works exactly as i intended; nobody's asking you to debug code for free; i'm
> looking for the kind of feedback the other respondent gave
Since you're being a bit of an ass about it, I took the liberty of
writing some tests for you. This only covers the very first class in
the file (I don't have all night). Two of the tests pass. The others
don't.
Since the interface is unclear (is signum allowed to be any signed
number, or only +/-1? The ordered comparison methods suggest the
former, but __eq__ only works with the latter) I chose to be
conservative and only wrote tests with +/-1. Otherwise test_eq would
also fail.
Please understand the point of this is not to shame you or anything.
As you said, we're not going to debug your code for you, but you asked
for criticism/suggestions, and I hope to make you see that suggesting
you write tests is a very valid and useful criticism of its own.
###
#) connectfour_test - python 3.6.1
###
import unittest
from connectfour import infinity
class InfinityTest(unittest.TestCase):
def test_repr(self):
self.assertEqual('+oo', repr(infinity(+1)))
self.assertEqual('-oo', repr(infinity(-1)))
def test_lt(self):
self.assertLess(infinity(-1), infinity(+1))
self.assertFalse(infinity(-1) < infinity(-1))
self.assertFalse(infinity(+1) < infinity(+1))
self.assertFalse(infinity(+1) < infinity(-1))
def test_le(self):
self.assertLessEqual(infinity(-1), infinity(+1))
self.assertLessEqual(infinity(-1), infinity(-1))
self.assertLessEqual(infinity(+1), infinity(+1))
self.assertFalse(infinity(+1) <= infinity(-1))
def test_gt(self):
self.assertFalse(infinity(-1) > infinity(+1))
self.assertFalse(infinity(-1) > infinity(-1))
self.assertFalse(infinity(+1) > infinity(+1))
self.assertGreater(infinity(+1), infinity(-1))
def test_ge(self):
self.assertFalse(infinity(-1) >= infinity(+1))
self.assertGreaterEqual(infinity(-1), infinity(-1))
self.assertGreaterEqual(infinity(+1), infinity(+1))
self.assertGreaterEqual(infinity(+1), infinity(-1))
def test_eq(self):
self.assertEqual(infinity(-1), infinity(-1))
self.assertEqual(infinity(+1), infinity(+1))
self.assertNotEqual(infinity(-1), infinity(+1))
self.assertNotEqual(infinity(+1), infinity(-1))
if __name__ == '__main__':
unittest.main()
--
https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, Nov 25, 2017 at 1:05 PM, wrote: > On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote: > >> Since you did not start with tests or write tests as you wrote code, ... > > why on earth would you assume that? instantiate "window" and you'll see it > works exactly as i intended; nobody's asking you to debug code for free; i'm > looking for the kind of feedback the other respondent gave > Tests, in this sense, means *automated* tests. Check out the "unittest" module, and perhaps read up on techniques of software testing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote: > Since you did not start with tests or write tests as you wrote code, ... why on earth would you assume that? instantiate "window" and you'll see it works exactly as i intended; nobody's asking you to debug code for free; i'm looking for the kind of feedback the other respondent gave peace stm -- https://mail.python.org/mailman/listinfo/python-list
Re: Issues encountered while launching the IDLE of python 3.7 64-bit I downloaded recently.
On Wed, Nov 22, 2017 at 4:29 AM, STEPHINEXT TUTORIALS < oladejist...@gmail.com> wrote: > Good morning, > I just downloaded the new version 3.7 for my windows operating system > 64-bits on your site. > The error I got while launching the IDLE is shown in the attached Picture. > I installed all the options and tried repairing it as well. > It would be appreciated if you could contact me back about the solution or > for further description. > I would love to get a response and help on the issue. > Thanks. > > I have subscribed to python-list also -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/24/17 5:46 PM, Ned Batchelder wrote: On 11/24/17 5:26 PM, Richard Damon wrote: Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in fact it is in XID_START) so should be available. U+2010 isn't allowed in Python 3 identifiers. The rules for identifiers are here: https://docs.python.org/3/reference/lexical_analysis.html#identifiers . U+2010 is in category Pd (http://www.fileformat.info/info/unicode/char/2010), which isn't one of the categories allowed in identifiers. Category Pc (http://www.fileformat.info/info/unicode/category/Pc/list.htm) is allowed, but it doesn't include anything that would look like a hyphen. --Ned. Looks like the site that I looked up characters in XID_CONTINUE/START was incorrect. Looks like not only is U+2010 not in any of the character classes that are put into ID_START or ID_CONTINUE but is in Pattern_Syntax which is explicitly removed from those categories. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/24/17 5:26 PM, Richard Damon wrote: Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in fact it is in XID_START) so should be available. U+2010 isn't allowed in Python 3 identifiers. The rules for identifiers are here: https://docs.python.org/3/reference/lexical_analysis.html#identifiers . U+2010 is in category Pd (http://www.fileformat.info/info/unicode/char/2010), which isn't one of the categories allowed in identifiers. Category Pc (http://www.fileformat.info/info/unicode/category/Pc/list.htm) is allowed, but it doesn't include anything that would look like a hyphen. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Fri, Nov 24, 2017 at 11:26 PM, Richard Damon wrote: > > Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in > fact it is in XID_START) so should be available. > Hi Richard. U+2010 is SyntaxError. 5 days ago I made a proposal on python-ideas, and we have already discussed many aspects including straw-man arguments about fonts,etc Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On 11/24/17 4:04 PM, Mikhail V wrote: On Fri, Nov 24, 2017 at 9:08 PM, Chris Angelico wrote: On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V wrote: I agree that one should have more choices, but people still can't really choose many things. I can't choose hyphen, I can't choose minus sign, and many tech people would probably want more operators. It counts probably not so *big* amount of people, compared to *all* people that potentially would say "oh how wonderful is it to be able to write in various scripts", still it is just a "use it at your own risk" thing at a minimum, and merely based on emotions rather than common sense. Regardless of what Unicode decides for classifications, there simply must be careful analysis how the major *Python* code actually looks in the end of all experiments. Especially true for characters in regard identifiers versus operators. And it's the "identifiers versus operators" question that is why you can't use hyphen in an identifier. Underscore is available as an ASCII joiner, and there are various non-ASCII joiners available too. Why is hyphen so important? Yes I understand this, so it is how Unicode defines joiners. Yeah, debates about the classifications can be hold forever, but one should not forget about the hyphen during these debates. Hyphen is used I think more then six hundreds years as a joiner (or probably some other classification term one prefer). And just comes so it works very well. Among Unicode joiners, middledot reminds of hyphen, but it is not used in typography for this task. So it is not good option and has issues in most fonts (too small or not aligned with lowercase). Often it is used to show up whitespace in editors, so it is kind of 'reserved'. Other joiners in unicode classification - well probably ok for a 1st April proposal. About importance, it was already covered in the proposal. Why it is SO important? It is rhetorical question. Important compared to what? Compared to the question, what one will eat and where sleep tomorrow? Then it is not so important. Mikhail Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in fact it is in XID_START) so should be available. What isn't available is U+002D (HYPHEN-MINUS) - because that is otherwise defined as the subtraction/negation operator. It may make your code harder to read, if your font doesn't make enough of a distinction between those characters -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python loop and web server (bottle) in the same script (Posting On Python-List Prohibited)
Lawrence D’Oliveiro wrote: I naturally concluded that you didn’t care about updates being momentarily held up by a web request in progress--which would happen anyway if you used threads, at least with CPython. Not necessarily -- the web processing is probably I/O bound, in which case the GIL will likely be released a lot of the time. But if you want to be sure the GIL won't get in the way, you would need to run the web and update tasks in separate processes. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Thursday, November 23, 2017 at 6:50:29 PM UTC, Mikhail V wrote: > Chris A wrote: > > >> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote: > >> > >>> Chris A wrote: > >>> > >>> Fortunately for the world, you're not the one who decided which > >>> characters were permitted in Python identifiers. The ability to use > >>> non-English words for function/variable names is of huge value; the > >>> ability to use a hyphen is of some value, but not nearly as much. > >> > >> Fortunately for the world we have Chris A. Who knows what is > >> fortunate and of huge values. > >> So is there any real world projects example of usage of non-latin scripts > >> in identifiers? Or is it still only a plan for the new world? > > > > Yes, I've used them personally. And I know other people who have. > > > Oh, I though it would be more impressive showcase for 'huge value'. > If we drop the benefit of the bare fact that you can do it, or you just > don't know English, how would describe the practical benefit? > If you don't know english, then programming at all will be just too hard. > (or one must define a new whole language specially for some local script) > > I mean for a real practical situation - for example for an average > Python programmer or someone who seeks a programmer job. > And who does not have a 500-key keyboard, and who has > a not enough high threshold of vision sensitivity to bear the look > of various scripts in one small text piece? > > Ok, I personally could find some practical usage for that, but > merely for fun. I doubt though that someone with less > typographical experience and overall computer literacy could > really make benefits even for personal usage. > > So - fun is one benefit. And fun is important. But is that the > idea behind it? > > > Mikhail Your normal rubbish. Do you ever give up with wasting our time? -- https://mail.python.org/mailman/listinfo/python-list
ANN: DIPY 0.13.0
Hello all, We are happy to announce a new public release of DIPY. This is mostly a maintenance release with extra fixes, speedups and minor changes of dependencies. *DIPY 0.13 (Tuesday, 24 October 2017)* This release received contributions from 13 developers (the full release notes are at: http://nipy.org/dipy/release0.13.html) *Highlights of this release include:* - Faster Local PCA implementation. - Fixed different issues with OpenMP and Windows / OSX. - Replacement of cvxopt module by cvxpy. - Replacement of Pytables module by h5py. - Updated API to support latest numpy version (1.14). - New user interfaces for visualization. - Large documentation update. To upgrade, run the following command in your terminal: *pip install --upgrade dipy* or *conda install -c conda-forge dipy* For any questions go to http://dipy.org, or send an e-mail to neuroimag...@python.org We also have an instant messaging service and chat room available at https://gitter.im/nipy/dipy Expect mad features in release 0.14 (Jan 2018)!!! On behalf of the DIPY developers, Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro http://dipy.org/developers.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Thursday, November 23, 2017 at 3:06:00 PM UTC-6, Chris Angelico wrote: > Seriously? Do I need to wrench this part out of you? This > was supposed to be the EASY question that everyone can > agree on, from which I can then draw my line of argument. Translation: "Dag-nab-it! You're supposed to answer my false dichotomy in a way that makes you look ~really~ bad, so that i can tear your argument apart ~really~ easy. Got it? Now stop clowning around and do it right this time!" -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Fri, Nov 24, 2017 at 9:08 PM, Chris Angelico wrote: > On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V wrote: >> I agree that one should have more choices, but >> people still can't really choose many things. >> I can't choose hyphen, I can't choose minus sign, >> and many tech people would probably want more operators. >> It counts probably not so *big* amount of people, compared to *all* >> people that potentially would say "oh how wonderful is it to be able >> to write in various scripts", still it is just a "use it at your own risk" >> thing at a minimum, and merely based on emotions rather than >> common sense. >> >> Regardless of what Unicode decides for classifications, there simply must >> be careful analysis how the major *Python* code actually looks in the end >> of all experiments. Especially true for characters in regard >> identifiers versus operators. > > And it's the "identifiers versus operators" question that is why you > can't use hyphen in an identifier. Underscore is available as an ASCII > joiner, and there are various non-ASCII joiners available too. Why is > hyphen so important? Yes I understand this, so it is how Unicode defines joiners. Yeah, debates about the classifications can be hold forever, but one should not forget about the hyphen during these debates. Hyphen is used I think more then six hundreds years as a joiner (or probably some other classification term one prefer). And just comes so it works very well. Among Unicode joiners, middledot reminds of hyphen, but it is not used in typography for this task. So it is not good option and has issues in most fonts (too small or not aligned with lowercase). Often it is used to show up whitespace in editors, so it is kind of 'reserved'. Other joiners in unicode classification - well probably ok for a 1st April proposal. About importance, it was already covered in the proposal. Why it is SO important? It is rhetorical question. Important compared to what? Compared to the question, what one will eat and where sleep tomorrow? Then it is not so important. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Fri, Nov 24, 2017 at 5:37 PM, Chris Angelico wrote: > On Sat, Nov 25, 2017 at 3:33 AM, Mikhail V wrote: >> On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico wrote: >> and in Python in particular, because they will be not only forced to learn some english, but also will have all 'pleasures' of multi-script editing. But wait, probably one can write python code in, say Arabic script *only*? How about such feature proposal? >>> >>> If Python supports ASCII identifiers only, people have no choice but >>> to transliterate. As it is, people get to choose which is better for >>> them - to transliterate or not to transliterate, that is the >>> readability question. >> >> Sure, let them choose. >> Transliteration though is way more reasonable solution. > > That right there has settled it: you agree that identifiers have to > use the broader Unicode set, not limited to ASCII. Otherwise they > can't choose. Everything else is down to style guides; the language > MUST support all alphabets so that people have this choice. That's a valid and somewhat obvious point. I agree that one should have more choices, but people still can't really choose many things. I can't choose hyphen, I can't choose minus sign, and many tech people would probably want more operators. It counts probably not so *big* amount of people, compared to *all* people that potentially would say "oh how wonderful is it to be able to write in various scripts", still it is just a "use it at your own risk" thing at a minimum, and merely based on emotions rather than common sense. Regardless of what Unicode decides for classifications, there simply must be careful analysis how the major *Python* code actually looks in the end of all experiments. Especially true for characters in regard identifiers versus operators. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers
On 11/24/2017 7:12 AM, bartc wrote: π = 3.141; That's great. But how do I type it on my keyboard? How do I view someone else's code on my crappy ASCII text editor? Input is a problem, but for reading, Python comes with a half-way decent Unicode BMP code editor, IDLE. No one needs to use a 'crappy ASCII text editor' for such code. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 11/24/2017 10:33 AM, namenobodywa...@gmail.com wrote: hi all i've just finished my first excursion into artificial intelligence with a game less trivial than tictactoe, and here it is in case anybody can offer criticism/suggestions/etc Since you did not start with tests or write tests as you wrote code, write a test file now. It will probably be at least as long as your current file. You will learn a lot about your code by doing so. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V wrote: > I agree that one should have more choices, but > people still can't really choose many things. > I can't choose hyphen, I can't choose minus sign, > and many tech people would probably want more operators. > It counts probably not so *big* amount of people, compared to *all* > people that potentially would say "oh how wonderful is it to be able > to write in various scripts", still it is just a "use it at your own risk" > thing at a minimum, and merely based on emotions rather than > common sense. > > Regardless of what Unicode decides for classifications, there simply must > be careful analysis how the major *Python* code actually looks in the end > of all experiments. Especially true for characters in regard > identifiers versus operators. And it's the "identifiers versus operators" question that is why you can't use hyphen in an identifier. Underscore is available as an ASCII joiner, and there are various non-ASCII joiners available too. Why is hyphen so important? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
Thank you Rick for well thought out argument. On Nov 24, 2017 12:44, "Rick Johnson" wrote: > On Thursday, November 23, 2017 at 9:57:12 PM UTC-6, Ben Finney wrote: > [...] > > This is a necessary consequence of increasing the diversity > > of people able to program in Python: people will express > > ideas originating in their own language, in Python code. > > For that diversity to increase, we English-fluent folk will > > necessarily become a smaller proportion of the programming > > community than we are today. That might be uncomfortable > > for us, but it is a necessary adaptation the community > > needs to undergo. > > Will your heroic crusade to bring equality to the shire also > include Python standard library modules written in languages > other than English? If so, then you'll need to contact > Guido, as PEP8 will require some editing. > > Speaking of GvR... > > And even if you did managed to bring multilingualism to > Python scripts and std-lib modules, wouldn't such > "diversity" be merely symbolic? > > Hmm, because, when we consider the make-up of pydev (aka: > nothing but English speaking dudes) we realize that there > really isn't any diversity at all. At least, not where it > matters. (aka: where the decision are being made) > > Furthermore, if we are to march headlong onto the glorious > battlefields of diversity and equality, for the sake of all > else, then, why should Guido's position be off limits? I > mean, sure, he may a brilliant man. But he's surely not the > most brilliant man on this planet, is he? > > And with that liberating thought in mind, may i offer an > excerpt, for your intellectual consumption, from one of the > most famous documents of all time? > > (emphasis mine) > > "Prudence, indeed, will dictate that governments long > established should not be changed for light and transient > causes; and accordingly, all experience hath shewn, that > [humankind] are more disposed to _suffer_ while evils are > _sufferable_, than to right themselves by abolishing the > forms to which they are "accustomed"; but when a ~long~ > train of abuses and usurpations, pursuing invariably the > same object, evinces a _design_ to reduce them under > absolute *DESPOTISM* -- It is their *RIGHT*! It is their > *DUTY*! -- to throw off such government and to provide new > guards for their future security" > > ...Declaration of Independence: July 4, 1776 > > I'm of the opinion that diversity is fine, so long as you > don't make the fatal mistake of "lopping off your nose to > spite your face". > > Take, for example, the accommodations our societies offer > for handicapped people -- from wheel chair ramps, to > reserved front-row parking spaces, to widened doorways, > etc... -- these accommodations do *NOT*, in any way, > undermine the accessability of healthy people who also utilize > these same public spaces. In fact, the worst consequence of > these accommodations might be that you and i must walk a few > more steps from our car to the market. > > Big deal! > > But what you are suggesting is not so much an > _accommodation_, as it is a fundamental fissure in our > ability to communicate, one that will fracture the community > far more than it is today. It would be as foolish as > mandating that everyone must have their legs lopped-off, so > that all will be "equal". > > Yes, diversity is great! But only when it welcomes outsiders > without undermining the practical cohesiveness of the wider > community. And if the result of your little "inclusivity > project" is merely the replacement of N domestic community > members with N foreign community members, foreigners who's > regional dialects will muck-up the communication process, > then it seems to me that what you have gained is merely a > fulfillment of your _own_ emotional needs, at the expense of > all. > > In conclusion. > > While a wise student of knowledge recognizes that: > > (1) social groups who have waxed into a homogenous block > actually undermine themselves, because they lack the > essential diversity of ideas required to see beyond the > walls of their own "box", and the confirmation bias that > infests such societies, will ensure that such a community is > an evolutionary dead end. > > The same student _also_ recognizes that: > > (2) a society which resembles a jig-saw-puzzle dumped > haphazardly on the floor, lacks the essential _cohesiveness_ > required to maintain a strong sense of _community_, a sense > which allows multiple individuals to work towards a common > goal, in manner this is both practical and efficient. > > Something to think about. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python
On 11/24/17 12:35 PM, Skip Montanaro wrote: I find it it interesting that the primary reason to want to limit the character set to ASCII is people thinking that it would make it hard for *them* to read/use the code, but no thought about how much harder it makes it on the original author/team to write code that is easily understood by THEM. I think you misunderstood my post. For that I apologize that I wasn't clear. I was only pointing out that there is a ton of inertia based on the long dominance of ASCII (and before that EBCDIC) and its downstream effects on computer entry systems. I know that there are likely semi-reasonable ways to enter accented characters on my keyboard, but they are unknown to me, and will likely be different on the different systems I use, so I've not bothered to learn any of them. One thing which occurred to me as I was typing my earlier message, but which I failed to include... I wonder if when you go to Dell (for example) to configure a computer, you can easily specify a non-ASCII keyboard for a machine destined for delivery to the US. Maybe it's trivial, but maybe it's just enough more difficult (slows delivery, costs a few bucks more, which of the alternatives should you choose?) that people think, "Ah hell, might as well just go with the ASCII keyboard." I'm clearly in the old fart camp at this point. Perhaps American software engineers half my age aren't afflicted by my career-long biases. Skip I doubt I am 1/2 your age (are you 120 yet?). The keyboard I normally use would be very hard to use for foreign characters, but I do understand that if I wanted to, I could easily get a keyboard designed for use in any other language. Some would take some training to learn how to use (like a Chinese keyboard). The fact that I was pointing out is that the fact that people are arguing that because *THEY* would have difficulty working with a code base (that they likely would never actually need access to) is a good reason from preventing others, who already HAVE the needed hardware/training from being able to make the code more readable to them. As far as the basic ability to enter arbitrary characters, most OSes have a generic entry method (like windows ALT-numbers method) and I think most have a character selector app to add arbitrary characters to the clipboard. Yes, this may not be very convenient for a lot of use but is possible. Also, it is generally possible to select an alternate keyboard map for your keyboard to enter other characters, you then just need to know (or have printed) the new mapping of the keyboard. It helps if you do this to have learned the new mapping, and how to touch type on that keyboard. Generally you can also get Keyboard Stickers to place on your keyboard if you are a hunt and pecker typist. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
> I find it it interesting that the primary reason to want to limit the > character set to ASCII is people thinking that it would make it hard for > *them* to read/use the code, but no thought about how much harder it makes > it on the original author/team to write code that is easily understood by > THEM. I think you misunderstood my post. For that I apologize that I wasn't clear. I was only pointing out that there is a ton of inertia based on the long dominance of ASCII (and before that EBCDIC) and its downstream effects on computer entry systems. I know that there are likely semi-reasonable ways to enter accented characters on my keyboard, but they are unknown to me, and will likely be different on the different systems I use, so I've not bothered to learn any of them. One thing which occurred to me as I was typing my earlier message, but which I failed to include... I wonder if when you go to Dell (for example) to configure a computer, you can easily specify a non-ASCII keyboard for a machine destined for delivery to the US. Maybe it's trivial, but maybe it's just enough more difficult (slows delivery, costs a few bucks more, which of the alternatives should you choose?) that people think, "Ah hell, might as well just go with the ASCII keyboard." I'm clearly in the old fart camp at this point. Perhaps American software engineers half my age aren't afflicted by my career-long biases. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On Thursday, November 23, 2017 at 9:57:12 PM UTC-6, Ben Finney wrote: [...] > This is a necessary consequence of increasing the diversity > of people able to program in Python: people will express > ideas originating in their own language, in Python code. > For that diversity to increase, we English-fluent folk will > necessarily become a smaller proportion of the programming > community than we are today. That might be uncomfortable > for us, but it is a necessary adaptation the community > needs to undergo. Will your heroic crusade to bring equality to the shire also include Python standard library modules written in languages other than English? If so, then you'll need to contact Guido, as PEP8 will require some editing. Speaking of GvR... And even if you did managed to bring multilingualism to Python scripts and std-lib modules, wouldn't such "diversity" be merely symbolic? Hmm, because, when we consider the make-up of pydev (aka: nothing but English speaking dudes) we realize that there really isn't any diversity at all. At least, not where it matters. (aka: where the decision are being made) Furthermore, if we are to march headlong onto the glorious battlefields of diversity and equality, for the sake of all else, then, why should Guido's position be off limits? I mean, sure, he may a brilliant man. But he's surely not the most brilliant man on this planet, is he? And with that liberating thought in mind, may i offer an excerpt, for your intellectual consumption, from one of the most famous documents of all time? (emphasis mine) "Prudence, indeed, will dictate that governments long established should not be changed for light and transient causes; and accordingly, all experience hath shewn, that [humankind] are more disposed to _suffer_ while evils are _sufferable_, than to right themselves by abolishing the forms to which they are "accustomed"; but when a ~long~ train of abuses and usurpations, pursuing invariably the same object, evinces a _design_ to reduce them under absolute *DESPOTISM* -- It is their *RIGHT*! It is their *DUTY*! -- to throw off such government and to provide new guards for their future security" ...Declaration of Independence: July 4, 1776 I'm of the opinion that diversity is fine, so long as you don't make the fatal mistake of "lopping off your nose to spite your face". Take, for example, the accommodations our societies offer for handicapped people -- from wheel chair ramps, to reserved front-row parking spaces, to widened doorways, etc... -- these accommodations do *NOT*, in any way, undermine the accessability of healthy people who also utilize these same public spaces. In fact, the worst consequence of these accommodations might be that you and i must walk a few more steps from our car to the market. Big deal! But what you are suggesting is not so much an _accommodation_, as it is a fundamental fissure in our ability to communicate, one that will fracture the community far more than it is today. It would be as foolish as mandating that everyone must have their legs lopped-off, so that all will be "equal". Yes, diversity is great! But only when it welcomes outsiders without undermining the practical cohesiveness of the wider community. And if the result of your little "inclusivity project" is merely the replacement of N domestic community members with N foreign community members, foreigners who's regional dialects will muck-up the communication process, then it seems to me that what you have gained is merely a fulfillment of your _own_ emotional needs, at the expense of all. In conclusion. While a wise student of knowledge recognizes that: (1) social groups who have waxed into a homogenous block actually undermine themselves, because they lack the essential diversity of ideas required to see beyond the walls of their own "box", and the confirmation bias that infests such societies, will ensure that such a community is an evolutionary dead end. The same student _also_ recognizes that: (2) a society which resembles a jig-saw-puzzle dumped haphazardly on the floor, lacks the essential _cohesiveness_ required to maintain a strong sense of _community_, a sense which allows multiple individuals to work towards a common goal, in manner this is both practical and efficient. Something to think about. -- https://mail.python.org/mailman/listinfo/python-list
Test, test, test
Testing 1 2 3 ... (you can ignore)
def gen_dotted_quad_clues(pfx, ips):
for ip in ips:
yield "%s:%s/32" % (pfx, ip)
dottedQuadList = ip.split(".")
if len(dottedQuadList) >= 1:
yield "%s:%s/8" % (pfx, dottedQuadList[0])
if len(dottedQuadList) >= 2:
yield "%s:%s.%s/16" % (pfx, dottedQuadList[0],
dottedQuadList[1])
if len(dottedQuadList) >= 3:
yield "%s:%s.%s.%s/24" % (pfx, dottedQuadList[0],
dottedQuadList[1],
dottedQuadList[2])
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On 11/24/17 11:41 AM, Skip Montanaro wrote: Because if I already can't understand the words, it will be more useful to me to be able to type them reliably at a keyboard, for replication, search, discussion with others about the code, etc. I am probably not alone in my Americo-centric world where I can't even easily type accented Latin-1 characters. I happen to be using Linux as I type this, but type at a Windows keyboard at work (ugh) and have long been a user of Macs (still have one or two at home). Might the problem be further multiplied by the number of different ways I have of entering text? Would Emacs running on Linux, but displaying on Windows be different than Chrome running directly on Linux? I will make a wild-ass guess and suggest that maybe, just maybe, those three major system types have different ways of typing accented characters. Consequently, I've never even tried to learn any of them. On the rare instance where I need to type an accented character, such as when typing Marc-André Lemburg's name properly, I ask Google for "accented e" and copy/paste an instance. That's a PITA, but worth it on the few occasions where I need it today. I suppose I would have to break down and learn how to properly enter such text should I need to Romanized text which might contain cedillas, accents and other diacritical marks... This is all not to suggest the goal isn't worth striving for, just that there exists a huge barrier - in the form of ASCII and its limiting effect on computer keyboard entry - to attaining Unicode identifier Nirvana. Perhaps for my next computer I should choose a non-ASCII keyboard option when configuring it. Skip I find it it interesting that the primary reason to want to limit the character set to ASCII is people thinking that it would make it hard for *them* to read/use the code, but no thought about how much harder it makes it on the original author/team to write code that is easily understood by THEM. Yes, code intended to be used by the broad community would be best to adhere to the community standard (and the community style guide should, if it doesn't already, have a rule about this). Code intended for internal usage is best to be as well understood by that group as possible. Some also bring up some of the issues with similar glyphs, as if we don't already have issues with things like 0 and O, 1 and l and I (depending on the font you use). This mostly comes down to self-inflicted pain, which can mostly be relieved with a style rule to avoid multi-language identifiers, perhaps checked with a special 'linter'. Since Python is white space sensitive, we already have the issue with the distinction between space and tab, which isn't normally obvious in many text editors (Though I suspect many Python programmers have their editors configured to largely avoid the issue). -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does asyncio.wait_for() need a timeout?
On Fri, Nov 24, 2017 at 9:35 AM, Ian Kelly wrote:
> On Fri, Nov 24, 2017 at 6:31 AM, Frank Millman wrote:
>> "Frank Millman" wrote in message news:ov5v3s$bv7$1...@blaine.gmane.org...
>>
>>> Below is a simple asyncio loop that runs two background tasks.
>>>
>> [...]
>>>
>>>
>>> Both take an optional timeout.
>>>
>>> If I use the first method without a timeout, the cancellation completes
>>> and the loop stops.
>>>
>>> If I use the second method without a timeout, the future is cancelled, but
>>> the program hangs.
>>>
>>> If I add a timeout to the second one, it behaves the same as the first
>>> one.
>>>
>>> Is there a reason for this?
>>>
>>
>> I have figured out half of the answer.
>>
>> 'timeout' is an optional argument when using wait(), but a required one when
>> using wait_for().
>>
>> Therefore asyncio is raising an exception.
>>
>> However, I do not understand why no traceback appears.
>
> Here's the output I get when I try it and then interrupt with Ctrl-C:
>
> $ python3 test.py
> From 1: 1
> From 2: 1
> From 1: 2
> From 2: 2
> From 1: 3
> From 2: 3
> From 1: 4
> From 2: 4
> From 1: 5
> From 2: 5
> From 1: 6
> counter1 cancelled
> ^CTraceback (most recent call last):
> File "test.py", line 27, in
> loop.run_forever()
> File "/usr/lib/python3.5/asyncio/base_events.py", line 345, in run_forever
> self._run_once()
> File "/usr/lib/python3.5/asyncio/base_events.py", line 1276, in _run_once
> event_list = self._selector.select(timeout)
> File "/usr/lib/python3.5/selectors.py", line 441, in select
> fd_event_list = self._epoll.poll(timeout, max_ev)
> KeyboardInterrupt
> Task exception was never retrieved
> future:
> exception=TypeError("wait_for() missing 1 required positional
> argument: 'timeout'",)>
> Traceback (most recent call last):
> File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
> result = coro.send(None)
> File "test.py", line 20, in counter2
> await asyncio.wait_for(cnt1) # hangs
> TypeError: wait_for() missing 1 required positional argument: 'timeout'
>
>
> The unhandled exception is shown as a warning when the loop exits. It
> can't be shown prior to that because there could be some other task,
> even one that hasn't been scheduled yet, that might try to get the
> result of the counter2 task and handle the exception.
By the way, this is what you get instead when you replace
run_forever() with run_until_complete(cnt2):
$ python3 test.py
>From 1: 1
>From 2: 1
>From 1: 2
>From 2: 2
>From 1: 3
>From 2: 3
>From 1: 4
>From 2: 4
>From 1: 5
>From 2: 5
>From 1: 6
counter1 cancelled
Traceback (most recent call last):
File "test.py", line 27, in
loop.run_until_complete(cnt2)
File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in
run_until_complete
return future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
raise self._exception
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "test.py", line 20, in counter2
await asyncio.wait_for(cnt1) # hangs
TypeError: wait_for() missing 1 required positional argument: 'timeout'
No need for Ctrl-C in this case because the loop notices that counter2
died and stops on its own, and you get a nice traceback explaining
what happened.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
> Because if I already can't understand the words, it will be more useful > to me to be able to type them reliably at a keyboard, for replication, > search, discussion with others about the code, etc. I am probably not alone in my Americo-centric world where I can't even easily type accented Latin-1 characters. I happen to be using Linux as I type this, but type at a Windows keyboard at work (ugh) and have long been a user of Macs (still have one or two at home). Might the problem be further multiplied by the number of different ways I have of entering text? Would Emacs running on Linux, but displaying on Windows be different than Chrome running directly on Linux? I will make a wild-ass guess and suggest that maybe, just maybe, those three major system types have different ways of typing accented characters. Consequently, I've never even tried to learn any of them. On the rare instance where I need to type an accented character, such as when typing Marc-André Lemburg's name properly, I ask Google for "accented e" and copy/paste an instance. That's a PITA, but worth it on the few occasions where I need it today. I suppose I would have to break down and learn how to properly enter such text should I need to Romanized text which might contain cedillas, accents and other diacritical marks... This is all not to suggest the goal isn't worth striving for, just that there exists a huge barrier - in the form of ASCII and its limiting effect on computer keyboard entry - to attaining Unicode identifier Nirvana. Perhaps for my next computer I should choose a non-ASCII keyboard option when configuring it. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Sat, Nov 25, 2017 at 3:33 AM, Mikhail V wrote: > On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico wrote: > >>> and in Python in particular, because they will be not only forced to learn >>> some english, but also will have all 'pleasures' of multi-script editing. >>> But wait, probably one can write python code in, say Arabic script *only*? >>> How about such feature proposal? >> >> If Python supports ASCII identifiers only, people have no choice but >> to transliterate. As it is, people get to choose which is better for >> them - to transliterate or not to transliterate, that is the >> readability question. > > Sure, let them choose. > Transliteration though is way more reasonable solution. That right there has settled it: you agree that identifiers have to use the broader Unicode set, not limited to ASCII. Otherwise they can't choose. Everything else is down to style guides; the language MUST support all alphabets so that people have this choice. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does asyncio.wait_for() need a timeout?
On Fri, Nov 24, 2017 at 6:31 AM, Frank Millman wrote:
> "Frank Millman" wrote in message news:ov5v3s$bv7$1...@blaine.gmane.org...
>
>> Below is a simple asyncio loop that runs two background tasks.
>>
> [...]
>>
>>
>> Both take an optional timeout.
>>
>> If I use the first method without a timeout, the cancellation completes
>> and the loop stops.
>>
>> If I use the second method without a timeout, the future is cancelled, but
>> the program hangs.
>>
>> If I add a timeout to the second one, it behaves the same as the first
>> one.
>>
>> Is there a reason for this?
>>
>
> I have figured out half of the answer.
>
> 'timeout' is an optional argument when using wait(), but a required one when
> using wait_for().
>
> Therefore asyncio is raising an exception.
>
> However, I do not understand why no traceback appears.
Here's the output I get when I try it and then interrupt with Ctrl-C:
$ python3 test.py
>From 1: 1
>From 2: 1
>From 1: 2
>From 2: 2
>From 1: 3
>From 2: 3
>From 1: 4
>From 2: 4
>From 1: 5
>From 2: 5
>From 1: 6
counter1 cancelled
^CTraceback (most recent call last):
File "test.py", line 27, in
loop.run_forever()
File "/usr/lib/python3.5/asyncio/base_events.py", line 345, in run_forever
self._run_once()
File "/usr/lib/python3.5/asyncio/base_events.py", line 1276, in _run_once
event_list = self._selector.select(timeout)
File "/usr/lib/python3.5/selectors.py", line 441, in select
fd_event_list = self._epoll.poll(timeout, max_ev)
KeyboardInterrupt
Task exception was never retrieved
future:
exception=TypeError("wait_for() missing 1 required positional
argument: 'timeout'",)>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "test.py", line 20, in counter2
await asyncio.wait_for(cnt1) # hangs
TypeError: wait_for() missing 1 required positional argument: 'timeout'
The unhandled exception is shown as a warning when the loop exits. It
can't be shown prior to that because there could be some other task,
even one that hasn't been scheduled yet, that might try to get the
result of the counter2 task and handle the exception.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico wrote: >> and in Python in particular, because they will be not only forced to learn >> some english, but also will have all 'pleasures' of multi-script editing. >> But wait, probably one can write python code in, say Arabic script *only*? >> How about such feature proposal? > > If Python supports ASCII identifiers only, people have no choice but > to transliterate. As it is, people get to choose which is better for > them - to transliterate or not to transliterate, that is the > readability question. Sure, let them choose. Transliteration though is way more reasonable solution. > >> As for non-english speaker who know some English already, >> could of course want to include identifiers in those scripts. >> But how about libraries? > > If you want to use numpy, you have to understand the language of > numpy. That's a lot of technical jargon, so even if you understand > English, you have to learn that. So there's ultimately no difference. That's what I'm saying. There will be anyway major parts of code in English and pretty much every already existing modules that can further help the developer will be in English, like it or not. >> Ok, so we return back to my original question: apart from >> ability to do so, how beneficial is it on a pragmatical basis? >> I mean, e.g. Cyrillic will introduce homoglyph issues. >> CJK and Arabic scripts are metrically and optically incompatible with >> latin, so such mixing will end up with messy look. So just for >> the experiment, yes, it's fun. > > Does it really introduce homoglyph issues in real-world situations, > though? Are there really cases where people can't figure out from > context what's going on? I haven't seen that happening. Usually there > are *entire words* (and more) in a single language, making it pretty > easy to figure out. The issues can be discussed long, but I have no doubt that even placing words in two different scripts on one text line is a bad idea, not only for source code. For mixing Cyrillic+Latin, yes, this also causes extra issues due to homoglyphs in many cases, I know it practically from everyday work with Cyrillic filenames, and from past experience with English-Russian textbooks. In textbooks at least I can help it by proper layout - separating them in tables, or putting in quotes or bold for inline usage. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, Nov 25, 2017 at 2:33 AM, wrote: > hi all > > i've just finished my first excursion into artificial intelligence with a > game less trivial than tictactoe, and here it is in case anybody can offer > criticism/suggestions/etc > Hi! You don't have a lot of comments or docstrings or anything, so it's not going to be easy to track down bugs. (I haven't tested your code, so in theory it could be 100% bug-free, but frankly I doubt it. No code is ever perfect :) ) > class infinity: > def __init__(self,signum): self.signum = signum > def __repr__(self): return '+oo' if self.signum > 0 else '-oo' > def __lt__(self,other): return False if self.signum > 0 else True > def __le__(self,other): return False if self.signum > 0 else True > def __gt__(self,other): return True if self.signum > 0 else False > def __ge__(self,other): return True if self.signum > 0 else False > def __eq__(self,other): return isinstance(other,infinity) and self.signum > == other.signum In Python, it's normal to name classes with a capital first letter, so "class Infinity" would be more normal. Instead of "True if some_condition else False", you can simply write "some_condition", and instead of "False if some_condition else True", you can write "not some_condition". > def getlines(board): > horizontal = [[(i, j+k) for k in range(4)] for i in range(6) for j in > range(7)] > vertical = [[(i+k, j) for k in range(4)] for i in range(6) for j in > range(7)] > positive = [[(i+k, j+k) for k in range(4)] for i in range(6) for j in > range(7)] > negative = [[(i+k, j-k) for k in range(4)] for i in range(6) for j in > range(7)] > linear = horizontal + vertical + positive + negative > lines = [line for line in linear if all(i in range(6) and j in > range(7) for (i,j) in line)] > return [[board[square] for square in line] for line in lines] Lining up your code vertically just looks ugly if you change to a different font. I wouldn't bother, personally. This is the kind of function that needs a docstring and some comments. What exactly is this doing? What are the "lines" of the board? What's the difference between "linear" and "lines"? What exactly is it returning? > def getwinner(board): > lines = getlines(board) > return ex if [ex]*4 in lines else oh if [oh]*4 in lines else None You seem to have fallen in love with the ternary 'if' expression. While it's normal for young lovers to shower each other with affection, it tends to get awkward for those watching you. I would recommend breaking some of these into straight-forward 'if' statements. > def getmover(board): > boardvalues = list(board.values()) > return ex if boardvalues.count(ex)==boardvalues.count(oh) else oh This is a very expensive way to avoid maintaining a "whose turn is it, anyway?" variable. > def getoptimum(mover): > return max if mover == ex else min I *think* this might be a critical part of your algorithm, but again, in the absence of explanatory information, I can't be sure. Are you following a basic minimax algorithm, where you assume that your opponent will always play optimally, and you attempt to minimize your potential losses? If so, definitely needs to be stated somewhere. (Also, if that's the case, your code is probably locked down to having the AI always playing the same side. Again, that needs to be stated clearly.) > def getvalue(winner,accessibles): > return infinity(+1) if winner == ex else infinity(-1) if winner == oh > else 0 if not accessibles else None Uh I don't even know what this is doing. Value of what? Why so much if/else in a single expression? > def heuristicvalue(board,depth): > winner = getwinner(board) > accessibles = getaccessibles(board) > value = getvalue(winner,accessibles) > if value != None: return value > if depth == 0:return guessvalue(board) > mover= getmover(board) > optimum = getoptimum(mover) > children = [makemove(board,column,mover) for column in accessibles] > return optimum(heuristicvalue(child,depth-1) for child in children) Anything with "heuristic" in the name is probably an important part of your algorithm. But I've looked at the code and I don't understand what it's doing. > def getmoves(board,depth): > accessibles = getaccessibles(board) > if not accessibles: return [] > mover = getmover(board) > optimum = getoptimum(mover) > children = [makemove(board,column,mover) for column in accessibles] > values= [heuristicvalue(child,depth) for child in children] > bestvalue = optimum(values) > return [accessibles[index] for index in range(len(accessibles)) if > values[index] == bestvalue] And this looks very similar to the previous one. Or at least, there are several identical lines. Hmm. > > [self.grid.squarebuttons[number].config(background=self.board[divmod(number,7)]) > for number in range(42
connect four (game)
hi all
i've just finished my first excursion into artificial intelligence with a game
less trivial than tictactoe, and here it is in case anybody can offer
criticism/suggestions/etc
peace
stm
###
#) connectfour - python 3.6.1
###
from tkinter import *
from random import choice
class infinity:
def __init__(self,signum): self.signum = signum
def __repr__(self): return '+oo' if self.signum > 0 else '-oo'
def __lt__(self,other): return False if self.signum > 0 else True
def __le__(self,other): return False if self.signum > 0 else True
def __gt__(self,other): return True if self.signum > 0 else False
def __ge__(self,other): return True if self.signum > 0 else False
def __eq__(self,other): return isinstance(other,infinity) and self.signum
== other.signum
ex, oh, blank = 'red black white' .split()
startboard = {(i,j):blank for i in range(6) for j in range(7)}
def getlines(board):
horizontal = [[(i, j+k) for k in range(4)] for i in range(6) for j in
range(7)]
vertical = [[(i+k, j) for k in range(4)] for i in range(6) for j in
range(7)]
positive = [[(i+k, j+k) for k in range(4)] for i in range(6) for j in
range(7)]
negative = [[(i+k, j-k) for k in range(4)] for i in range(6) for j in
range(7)]
linear = horizontal + vertical + positive + negative
lines = [line for line in linear if all(i in range(6) and j in
range(7) for (i,j) in line)]
return [[board[square] for square in line] for line in lines]
def getwinner(board):
lines = getlines(board)
return ex if [ex]*4 in lines else oh if [oh]*4 in lines else None
def getmover(board):
boardvalues = list(board.values())
return ex if boardvalues.count(ex)==boardvalues.count(oh) else oh
def getoptimum(mover):
return max if mover == ex else min
def getaccessibles(board):
return [j for j in range(7) if board[0,j] == blank]
def getvalue(winner,accessibles):
return infinity(+1) if winner == ex else infinity(-1) if winner == oh else
0 if not accessibles else None
def makemove(board,column,mover):
board = board.copy()
empties = [row for row in range(6) if board[row,column] == blank]
if not empties: return board
board[max(empties),column] = mover
return board
def takemoveback(board,column):
board = board.copy()
occupied = [row for row in range(6) if board[row,column] != blank]
if not occupied: return board
board[min(occupied),column] = blank
return board
def guessvalue(board):
lines = getlines(board)
exs = [line for line in lines if line.count(ex)==3 and line.count(oh)==0]
ohs = [line for line in lines if line.count(oh)==3 and line.count(ex)==0]
return len(exs)-len(ohs)
def heuristicvalue(board,depth):
winner = getwinner(board)
accessibles = getaccessibles(board)
value = getvalue(winner,accessibles)
if value != None: return value
if depth == 0:return guessvalue(board)
mover= getmover(board)
optimum = getoptimum(mover)
children = [makemove(board,column,mover) for column in accessibles]
return optimum(heuristicvalue(child,depth-1) for child in children)
def getmoves(board,depth):
accessibles = getaccessibles(board)
if not accessibles: return []
mover = getmover(board)
optimum = getoptimum(mover)
children = [makemove(board,column,mover) for column in accessibles]
values= [heuristicvalue(child,depth) for child in children]
bestvalue = optimum(values)
return [accessibles[index] for index in range(len(accessibles)) if
values[index] == bestvalue]
class grid:
def __init__(self,window):
self.window= window
self.boardframe= Frame(window.root)
self.rowframes = [Frame(self.boardframe) for anonymous in range(6)]
self.squarebuttons = [Button(self.rowframes[number//7], width=3,
command=self.window.squarecommand(number), background=blank) for number in
range(42)]
def pack(self):
self.boardframe .pack(side=TOP)
[frame .pack(side=TOP) for frame in self.rowframes]
[button .pack(side=LEFT) for button in self.squarebuttons]
class caption:
def __init__(self,window):
self.window = window
self.statusframe = Frame(window.root)
self.statuslabel = Label(self.statusframe, height=2)
def pack(self):
self.statusframe .pack(side=TOP)
self.statuslabel .pack(side=LEFT)
class buttonpanel:
def __init__(self,window,depth):
self.window = window
self.controlframe= Frame(window.root)
self.makemoveframe = Frame(self.controlframe)
self.takebackframe = Frame(self.controlframe)
self.startoverframe = Frame(self.controlframe)
self.makemovebutton = Button(self.makemoveframe, text='make move',
command=self.window.move
Python para whatsapp em massa.
Bom dia. Gostaria de saber quais processos eu preciso fazer para aprender a programar em python. Preciso especificamente programar um software para envio em massa de whatsapp e não sei por onde começar. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does asyncio.wait_for() need a timeout?
"Frank Millman" wrote in message news:ov5v3s$bv7$1...@blaine.gmane.org... Below is a simple asyncio loop that runs two background tasks. [...] Both take an optional timeout. If I use the first method without a timeout, the cancellation completes and the loop stops. If I use the second method without a timeout, the future is cancelled, but the program hangs. If I add a timeout to the second one, it behaves the same as the first one. Is there a reason for this? I have figured out half of the answer. 'timeout' is an optional argument when using wait(), but a required one when using wait_for(). Therefore asyncio is raising an exception. However, I do not understand why no traceback appears. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Python loop and web server (bottle) in the same script (Posting On Python-List Prohibited)
That's right. Update task has precedence. Looks like it is not an easy task. Regards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers
bartc :
> On 24/11/2017 11:56, Stefan Ram wrote:
>>Java allowed Unicode in identifiers right from the get-go
>>(1995). I.e., one can write an assignment statement such as
>>
>> π = 3.141;
>
> That's great. But how do I type it on my keyboard? How do I view someone
> else's code on my crappy ASCII text editor?
That's a different problem entirely.
I remember the 1980's when terminals only supported 7-bit characters,
but Finnish people needed to be able to type Finnish text. The solution
was to ditch unneeded American punctuation characters. Thus, your
first-ever C-program might have looked like this:
main(argc, argv)
int argc;
char argvÄÅ;
ä
printf("Hello, world!Ön");
å
> German isn't very challenging apart from a couple of umlauts and that
> funny symbol for ss that looks like a Greek beta. And perhaps in
> Germany, keyboards will already take care of those.
>
> But which keyboards will have π [copied from the one above!]?
I can map any character onto any key. In fact, my keyboard mapping is
heavily personalized.
I must admit, though, that I haven't mapped π onto any key.
It would be naïve to assume, though, that the problem doesn't apply to
English. You never had to type a résumé—or use non-ASCII punctuation? If
you should stray out of the USA, it wouldn't hurt to carry some € or £. I
*have* mapped those keys onto my keyboard.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers
On 2017-11-24 13:12, bartc wrote: > On 24/11/2017 11:56, Stefan Ram wrote: >> Karsten Hilbert writes: >>> However, the main point has been answered - Python already >>> does what is talked about. End of story. >> >> Java allowed Unicode in identifiers right from the get-go >> (1995). I.e., one can write an assignment statement such as >> >> π = 3.141; > > That's great. But how do I type it on my keyboard? How do I view someone > else's code on my crappy ASCII text editor? ASCII editors are not text editors. > >> . The Java community decided to ignore this and only use >> latin letters and arabic digits (i.e., »pi1«) and English >> words, to support the (international) exchange of code. >> >> (However, for a beginner's tutorial in German, I might use >> identifiers based on German words.) > > > German isn't very challenging apart from a couple of umlauts and that > funny symbol for ss that looks like a Greek beta. And perhaps in > Germany, keyboards will already take care of those. > > But which keyboards will have π [copied from the one above!]? > > Apart perhaps from the ones in Greece, where π might already be heavily > used in the same way we use 'p'. > -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers
On 24/11/2017 11:56, Stefan Ram wrote: Karsten Hilbert writes: However, the main point has been answered - Python already does what is talked about. End of story. Java allowed Unicode in identifiers right from the get-go (1995). I.e., one can write an assignment statement such as π = 3.141; That's great. But how do I type it on my keyboard? How do I view someone else's code on my crappy ASCII text editor? . The Java community decided to ignore this and only use latin letters and arabic digits (i.e., »pi1«) and English words, to support the (international) exchange of code. (However, for a beginner's tutorial in German, I might use identifiers based on German words.) German isn't very challenging apart from a couple of umlauts and that funny symbol for ss that looks like a Greek beta. And perhaps in Germany, keyboards will already take care of those. But which keyboards will have π [copied from the one above!]? Apart perhaps from the ones in Greece, where π might already be heavily used in the same way we use 'p'. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python loop and web server (bottle) in the same script (Posting On Python-List Prohibited)
Lawrence D’Oliveiro wrote: On Friday, November 24, 2017 at 3:27:17 AM UTC+13, zlju...@gmail.com wrote: Looks like I need some sort of parallelization. This is why coroutines were added to Python. Threading is notoriously bug-prone, and is best avoided in most situations. The OP claimed that the timing of the update task is critical, and needs to take priority over serving web pages. Coroutines won't be able to achieve that. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Thu, Nov 23, 2017 at 05:47:04PM -0700, Ian Kelly wrote: > > Understanding, let alone being able to read, code written in Arabic ? > > People are going to write code in Arabic whether you like it or not, > because not everybody speaks English, and not everybody who does > *wants* to use it. Now, would you prefer to read code where the > variable names are written in Arabic script, or where the variable > names are still in Arabic but transliterated to Latin characters? > Either way, you're not going to be able to understand it, so I'm not > sure why it makes a difference to you. I can visually pattern match "words" based on Latin characters. I can't with Arabic letters. So that answers the "would you prefer" part. However, the main point has been answered - Python already does what is talked about. End of story. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- https://mail.python.org/mailman/listinfo/python-list
