Re: connect four (game)
On 11/24/2017 9:05 PM, [email protected] 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, ... that I could tell ... I agree that I should have stuck in a qualifier, such as 'apparently'. why on earth would you assume that? I inferred (not assumed) that because a) people routinely post code here and on Stackoverflow without including or mentioning runnable automated tests; b) you said 'here it is' without a word about tests; c) your code has no docstrings or other function by function doc, and one can hardly write tests without them. Was I right or are you exceptional? instantiate "window" and you'll see it works exactly as i intended; I did, and it looks buggy to me. The top and left frame lines are missing. If I click a square, the bottom square in the column lights up. But then I have no idea whether those are your intentions or not. nobody's asking you to debug code for free; i'm looking for the kind of feedback the other respondent gave. I read Chris's answer and intentionally did not repeat. Anyway, I think the best advice I could give you, based on experience writing and reviewing code, if you do not already have complete coverage, is to write (more?) automated tests. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Pros and cons of Python sources?
Some time ago I was advised that having a Python installation based on several sources (pip and Debian's repos in my case) is not a good idea. I need to tidy up my installation and I don't know what to opt for and what to opt out. What are the pros and cons of the alternatives including the ones I haven't mentioned? Completeness, currency, bugs... /Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On Sat, 25 Nov 2017 09:20:44 +, Martin Schöön wrote: > Some time ago I was advised that having a Python installation based on > several sources (pip and Debian's repos in my case) is not a good idea. > I need to tidy up my installation and I don't know what to opt for and > what to opt out. > > What are the pros and cons of the alternatives including the ones I > haven't mentioned? Completeness, currency, bugs... > > /Martin Personally i would always use the Distro repository first & only use a 3rd party option (including pip) if the package I required was not available this ensures compatibility with the OS. -- I must get out of these wet clothes and into a dry Martini. -- Alexander Woolcott -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Friday, November 24, 2017 at 12:20:29 AM UTC+5:30, Mikhail V wrote: > 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? Are you under-estimating the fun-value? Python 3.5.3 (default, Sep 14 2017, 22:58:41) [GCC 6.3.0 20170406] on linux Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> A = 1 >>> Α = 2 >>> А = 3 >>> (A, Α, А) (1, 2, 3) >>> # And there are 5 other variations on this magic trick >>> # Or if you prefer… >>> A == Α False >>> Now compare with the boring spoilsport called python 2: Python 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> A = 1 >>> Α = 2 File "", line 1 Α = 2 ^ SyntaxError: invalid syntax >>> Personally I feel that there should be a law against languages that disallow the creation of magic tricks!¡! -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Saturday, November 25, 2017 at 6:03:52 PM UTC+5:30, Rustom Mody wrote: > On Friday, November 24, 2017 at 12:20:29 AM UTC+5:30, Mikhail V wrote: > > 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? > > Are you under-estimating the fun-value? > > Python 3.5.3 (default, Sep 14 2017, 22:58:41) > [GCC 6.3.0 20170406] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> python.el: native completion setup loaded > >>> A = 1 > >>> Α = 2 > >>> А = 3 > >>> (A, Α, А) > (1, 2, 3) > >>> # And there are 5 other variations on this magic trick > >>> # Or if you prefer… > >>> A == Α > False > >>> > > Now compare with the boring spoilsport called python 2: > > Python 2.7.13 (default, Jan 19 2017, 14:48:08) > [GCC 6.3.0 20170118] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> python.el: native completion setup loaded > >>> A = 1 > >>> Α = 2 > File "", line 1 > Α = 2 > ^ > SyntaxError: invalid syntax > >>> > > Personally I feel that there should be a law against languages that disallow > the creation of magic tricks!¡! I should mention also that some languages are even more advanced in their jovialness regarding unicode tricks Haskell: GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> let flag = 1 Prelude> let flag = 2 Prelude> flag == flag False Prelude> (flag, flag) (2,1) Prelude> Python3 is quite boring by contrast: Python 3.5.3 (default, Sep 14 2017, 22:58:41) [GCC 6.3.0 20170406] on linux Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> flag = 1 >>> flag = 2 >>> flag == flag True >>> (flag, flag) (2, 2) >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 25/11/2017 04:43, Ian Kelly wrote:
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()
Where are your unittests for these unittests?
Or is this kind of code immune from testing?
Actually I've no idea what these tests are supposed to prove. They are
to do with one class called 'infinity', which is never used in the rest
of the program apart from one line.
I established that within a few seconds, and I would concentrate on what
'infinity' is actually for, rather than go to considerable lengths to
test a class that may not actually be needed.
And there's a quite lot left of the rest of the program to worry about too!
If you add 'window()' at the end of the program, then it seems to run on
Python 3. I'd play around with it first before thinking up strategies
for testing it.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
How to shut down a TCPServer serve_forever() loop?
Hi all,
My problem in summary is that my use of the shutdown() method only shuts
down a server after the next TCP request is received.
I have a TCP server created in the run() method of a thread.
class TCPlistener( Thread ):
def run( self ):
with socketserver.TCPServer( ("localhost", ),
ConnHandler ) as server:
self.server = server
print( "TCP listener on: %s:%d" % ( self.host,
self.port ) )
self.server.serve_forever()
print( "TCPlistener:run() ending" )
ConnHandler is a simple echo class with only a handle() method
The main bit of the program is
if __name__ == "__main__":
serverThrd = TCPlistener()
serverThrd.start() #start TCP IP server listening
print("server started")
ch = getche() #wait for key press
print()
serverThrd.server.shutdown()
print( "main ending" )
Everying works as expected, numerous connections can be made and the
received text is echoed back.
The issue is that if I press a key on the keyboard the key is
immediately shown on the screen but then the shutdown() call blocks
until another TCP connection is made, text is echoed back and only then
does serve_forever()return followed by shutdown()returning as can be
seen from the console session,
>>python36 TCPIPserver.py
server started
TCP listener on: localhost:
q #pressed 'q' key
127.0.0.1 wrote: #Sent some text from PuTTY
b'SOME TEXT'
TCPlistener:run() ending
main ending
How can I get shutdown()to shut down the server immediately without
waiting for the next TCP connection?
Regards,
JOhn
--
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 11:33 PM, Rustom Mody wrote: > Personally I feel that there should be a law against languages that disallow > the creation of magic tricks!¡! I agree. The programming language should also ensure that your program will terminate eventually, that it is bug-free (this can actually be done in Python - all you have to do is type-annotate all your functions to return the correct values), and that it is optimally implemented. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On 11/25/2017 02:20 AM, Martin Schöön wrote: > Some time ago I was advised that having a Python installation > based on several sources (pip and Debian's repos in my case) > is not a good idea. I need to tidy up my installation and I > don't know what to opt for and what to opt out. > > What are the pros and cons of the alternatives including the > ones I haven't mentioned? Completeness, currency, bugs... The problem with mixing repository-installed packages with pip-installed packages is that there's always a chance a Debian update will overwrite a pip package, possibly with an older version. Or a pip-installed package might bring in a new version that's not compatible with some debian-installed package, breaking something. One solution to this issue is to use Python the python virtualenv facility to create a special python root you can work in for your project, and pip install things you need into that place, without worrying about the issue I mentioned before. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: > On 11/25/2017 02:20 AM, Martin Schöön wrote: > > Some time ago I was advised that having a Python installation > > based on several sources (pip and Debian's repos in my case) > > is not a good idea. I need to tidy up my installation and I > > don't know what to opt for and what to opt out. > > > > What are the pros and cons of the alternatives including the > > ones I haven't mentioned? Completeness, currency, bugs... > > The problem with mixing repository-installed packages with pip-installed > packages is that there's always a chance a Debian update will overwrite > a pip package, possibly with an older version. Or a pip-installed > package might bring in a new version that's not compatible with some > debian-installed package, breaking something. On (recent?) debian/ubuntu pip seems to use the 'user-scheme' which means pip runs without sudo and installs in ~/.local/lib So I dont believe literal overwriting would occur What could occur is shadowing — two versions of package foo and an unclarity of which is in use… Alister's suggestion is what I always try first. Doesnt always work because OS packages could be stale and/or non-existent -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote: > Where are your unittests for these unittests? Taking this question more seriously than it deserves: the tests for the unittest module itself are at https://hg.python.org/cpython/file/tip/Lib/unittest/test. Yes, unittest has tests of itself. As for tests of the tests, that's getting a bit absurd, don't you think? Then we'd have to write tests of the tests of the tests. And then those tests would need tests. It's turtles all the way down. No, the point of having unit tests is to build confidence that the code in question works correctly. It's *possible* that the code is broken, and that the test is also broken in a way that hides the brokenness of the code, but this is much less likely than the case where just the code is broken. This is also the reason why the philosophy of test-drive development stipulates that one should write the test *first*, run it and watch it fail (this ensures that the test is actually testing *something*) and then and only then write the code to make the test pass. > Or is this kind of code immune from testing? It is the production code, not the test code, that we wish to have confidence in. > Actually I've no idea what these tests are supposed to prove. They are to do > with one class called 'infinity', which is never used in the rest of the > program apart from one line. As I stated in my earlier reply, I just started at the top of the file and wrote some tests. I didn't do anything for the rest of the program because I was merely trying to demonstrate the technique, not write hundreds of lines of tests for the OP. > I established that within a few seconds, and I would concentrate on what > 'infinity' is actually for, rather than go to considerable lengths to test a > class that may not actually be needed. If the class is used, then it's needed. There is a concept in software testing called "code coverage". This represents the idea that every statement in a program should be exercised at least once by the tests. This is one of the reasons why much software testing focuses on unit testing: if we break the program apart into units, and we thoroughly test each unit, then we should end up with complete coverage of the program as a whole. > If you add 'window()' at the end of the program, then it seems to run on > Python 3. I'd play around with it first before thinking up strategies for > testing it. "Seems to run" and "works correctly" are very different things. -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On Friday, November 24, 2017 at 10:52:47 PM UTC+5:30, Rick Johnson wrote: > Furthermore, if we are to march headlong onto the glorious > battlefields of diversity and equality… Obligatory viewing for those who underappreciate diversity, equality and such https://youtu.be/Zh3Yz3PiXZw [My old colleague, a numerical analyst pointed out to me today that the 'correct answer' is not twenty two thousand but twenty million two thousand] -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly wrote: > On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote: >> Where are your unittests for these unittests? > > No, the point of having unit tests is to build confidence that the > code in question works correctly. It's *possible* that the code is > broken, and that the test is also broken in a way that hides the > brokenness of the code, but this is much less likely than the case > where just the code is broken. This is also the reason why the > philosophy of test-drive development stipulates that one should write > the test *first*, run it and watch it fail (this ensures that the test > is actually testing *something*) and then and only then write the code > to make the test pass. To be fair, TDD doesn't actually prove that the test isn't broken. It only protects you against one class of error: tests that actually aren't testing anything. Proponents of TDD will argue that this class of error is quite common; true or not, it's still only one particular kind of failure. It's definitely possible for tests to be wrong in such a way that they don't detect faulty code. So what do we do? WE TEST BY HAND. Ultimately, unit testing is a tool, not a magic wand. It's up to us to actually put it to use to improve code quality. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Sat, Nov 25, 2017 at 10:02 AM, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly wrote: >> On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote: >>> Where are your unittests for these unittests? >> >> No, the point of having unit tests is to build confidence that the >> code in question works correctly. It's *possible* that the code is >> broken, and that the test is also broken in a way that hides the >> brokenness of the code, but this is much less likely than the case >> where just the code is broken. This is also the reason why the >> philosophy of test-drive development stipulates that one should write >> the test *first*, run it and watch it fail (this ensures that the test >> is actually testing *something*) and then and only then write the code >> to make the test pass. > > To be fair, TDD doesn't actually prove that the test isn't broken. It > only protects you against one class of error: tests that actually > aren't testing anything. Proponents of TDD will argue that this class > of error is quite common; true or not, it's still only one particular > kind of failure. It's definitely possible for tests to be wrong in > such a way that they don't detect faulty code. > > So what do we do? WE TEST BY HAND. Ultimately, unit testing is a tool, > not a magic wand. It's up to us to actually put it to use to improve > code quality. Certainly. I wasn't trying to advocate for TDD here, which I don't even practice regularly myself. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Nov 25, 2017, at 9:16 AM, Ian Kelly wrote: > >> On Sat, Nov 25, 2017 at 10:02 AM, Chris Angelico wrote: >>> On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly wrote: On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote: Where are your unittests for these unittests? >>> >>> No, the point of having unit tests is to build confidence that the >>> code in question works correctly. It's *possible* that the code is >>> broken, and that the test is also broken in a way that hides the >>> brokenness of the code, but this is much less likely than the case >>> where just the code is broken. This is also the reason why the >>> philosophy of test-drive development stipulates that one should write >>> the test *first*, run it and watch it fail (this ensures that the test >>> is actually testing *something*) and then and only then write the code >>> to make the test pass. >> >> To be fair, TDD doesn't actually prove that the test isn't broken. It >> only protects you against one class of error: tests that actually >> aren't testing anything. Proponents of TDD will argue that this class >> of error is quite common; true or not, it's still only one particular >> kind of failure. It's definitely possible for tests to be wrong in >> such a way that they don't detect faulty code. >> >> So what do we do? WE TEST BY HAND. Ultimately, unit testing is a tool, >> not a magic wand. It's up to us to actually put it to use to improve >> code quality. > > Certainly. I wasn't trying to advocate for TDD here, which I don't > even practice regularly myself. > -- > https://mail.python.org/mailman/listinfo/python-list For anyone who is interested, "Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript" by Harry J.W. Percival. The second edition came out this year. A good introduction to unit and function testing. Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 11/25/2017 06:00 AM, bartc wrote: > And there's a quite lot left of the rest of the program to worry about too! > > If you add 'window()' at the end of the program, then it seems to run on > Python 3. I'd play around with it first before thinking up strategies > for testing it. Actually, no. Unit testing ideally should be done for each and every class as they are being written (before they are written in fact), no matter how small and trivial the class. That way as you compose larger and larger units of code, the chances of things being right is greater compared to doing it the other way around. You may argue that testing doesn't matter for his small game, written for his own education and amusement. The fact is that software in general is of abysmal quality across the boards, and promoting a habit of unit testing is good, even for trivial, home-grown stuff. -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Saturday, November 25, 2017 at 5:00:12 AM UTC-8, bartc wrote: > Actually I've no idea what these tests are supposed to prove. me neither; i think you guys may be getting me out of my depth now > They are to do with one class called 'infinity', which is never used in the > rest > of the program apart from one line. > > I established that within a few seconds, and I would concentrate on what > 'infinity' is actually for, rather than go to considerable lengths to > test a class that may not actually be needed. my current version of "infinity" looks like this class Infinity: def __init__(self,signum): self.signum = (+1) if signum > 0 else (-1) def __repr__(self): return '+oo' if self.signum == (+1) else '-oo' def __lt__(self,other): return self.signum == (-1) def __le__(self,other): return self.signum == (-1) def __gt__(self,other): return self.signum == (+1) def __ge__(self,other): return self.signum == (+1) def __eq__(self,other): return isinstance(other,Infinity) and self.signum == other.signum the idea is that there should be exactly one object posinf (positive infinity) that compares as strictly greater than any number ever considered, and exactly one object neginf that compares as strictly less; as the code stands now there is no reason not to use +/-70 in that capacity; the "infinity" class is there so that the game-playing parts of the code (which at present are intentionally as primitive as possible) can be modified more smoothly later; the single place where "infinity" is instantiated is in the function "getvalue", which returns the value of a finished game: def getvalue(winner,accessibles): return Infinity(+1) if winner == ex else Infinity(-1) if winner == oh else 0 if not accessibles else None if ex has won then the value of the game is posinf; if oh has won then it's neginf; if the game is tied (no winner but no accessible columns remaining) then the value of the game is zero; otherwise the game is not finished and its finished value is None peace stm -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote: > 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? producing documentation is an extremely difficult task for me, but i've come up with the following: """ makelines(length,numrows,numcolumns) IS THE LIST OF ALL LISTS L, WITH LENGTH length, OF COORDINATES FROM A numrows x numcolumns MATRIX, SUCH THAT THE ENTRIES OF L ALL LIE IN A LINE: LET horizontal BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A HORIZONTAL LINE LET vertical BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A VERTICAL LINE LET downward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN A DOWNWARD-SLOPING DIAGONAL LINE LET upward BE ALL THE APPROPRIATE-LENGTH LISTS WHOSE ENTRIES LIE IN AN UPWARD-SLOPING DIAGONAL LINE THEN makelines(length,numrows,numcolumns) IS THE UNION OF ALL THE AFOREMENTIONED SETS """ def makelines(length,numrows,numcolumns): horizontal = [[(i, j+k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] vertical = [[(i+k, j) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] downward = [[(i+k, j+k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] upward = [[(i+k, j-k) for k in range(length)] for i in range(numrows) for j in range(numcolumns)] linear = horizontal + vertical + downward + upward return [line for line in linear if all(i in range(6) and j in range(7) for (i,j) in line)] def getlines(board): coordlines = makelines(4,6,7) ## GLOBAL return [[board[square] for square in line] for line in coordlines i tried to remove all the superfluous spaces from that, but lining up code vertically is very helpful to me, so i don't think i can really dispense with the practice peace stm -- https://mail.python.org/mailman/listinfo/python-list
Compile Python 3 interpreter to force 2-byte unicode
Hi, my goal is to obtain an interpreter that internally uses UCS-2. Such a simple code should print 65535: import sys print sys.maxunicode This is enabled in Windows, but I want the same in Linux. What options have I pass to the configure script? w. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 9:05 AM, wrote: > Hi, my goal is to obtain an interpreter that internally > uses UCS-2. Such a simple code should print 65535: > > import sys > print sys.maxunicode > > This is enabled in Windows, but I want the same in Linux. > What options have I pass to the configure script? Why do you want to? What useful value do you have in creating this buggy interpreter? Ever since Python 3.3, that has simply not been an option. The bug has been solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote: > I did, and it looks buggy to me. The top and left frame lines are > missing. If I click a square, the bottom square in the column lights > up. But then I have no idea whether those are your intentions or not. i hadn't noticed about the frame lines, but it's the same for me; but i'm hoping you meant to write that the TOP square in a column flashes when you "drop a token" down that column; if you really meant the bottom one then i'm totally baffled that it could be the top one for me and the bottom one for you ... is that something that can happen because of a bug? sorry if you were offended by what i wrote before; i didn't understand what you meant peace stm -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On 11/25/2017 4:57 PM, [email protected] wrote: On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote: I did, and it looks buggy to me. The top and left frame lines are missing. If I click a square, the bottom square in the column lights up. But then I have no idea whether those are your intentions or not. i hadn't noticed about the frame lines, but it's the same for me; but i'm hoping you meant to write that the TOP square in a column flashes when you "drop a token" down that column; All squares start white. Only the bottom square turns red or black, after perhaps a .3 second delay during which there is some jitter in white squares above, which could be the effect of white flashing white. if you really meant the bottom one then i'm totally baffled that it could be the top one for me and the bottom one for you ... is that something that can happen because of a bug? I am running on Windows 10 from IDLE (which should not affect your code) with 3.7.0a2 with tk 8.6.6. The OS and tk version could have an effect, though top versus bottom is hard to fathom. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On 11/25/2017 5:12 PM, Chris Angelico wrote: On Sun, Nov 26, 2017 at 9:05 AM, wrote: Hi, my goal is to obtain an interpreter that internally uses UCS-2. Such a simple code should print 65535: import sys print sys.maxunicode This is enabled in Windows, but I want the same in Linux. What options have I pass to the configure script? You must be trying to compile 2.7. There may be Linux distributions that compile this way. If you want to use, or ever encounter, non-BMP chars, using surrogate pairs is problematical. By my reading of the official UCS-2 docs, Python's old 16-bit unicode implementation is not fully compliant. Others have claimed that is it not a UCS-2 implementation. Why do you want to? What useful value do you have in creating this buggy interpreter? Ever since Python 3.3, that has simply not been an option. The bug has been solved. If you want to seriously work with unicode, many recommend using modern Python. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 10:59 AM, Terry Reedy wrote: > On 11/25/2017 5:12 PM, Chris Angelico wrote: >> >> On Sun, Nov 26, 2017 at 9:05 AM, wrote: >>> >>> Hi, my goal is to obtain an interpreter that internally >>> uses UCS-2. Such a simple code should print 65535: >>> >>>import sys >>>print sys.maxunicode >>> >>> This is enabled in Windows, but I want the same in Linux. >>> What options have I pass to the configure script? > > > You must be trying to compile 2.7. There may be Linux distributions that > compile this way. If you want to use, or ever encounter, non-BMP chars, > using surrogate pairs is problematical. By my reading of the official UCS-2 > docs, Python's old 16-bit unicode implementation is not fully compliant. > Others have claimed that is it not a UCS-2 implementation. See subject line. OP wishes to compile Python 3 (and almost certainly not 3.1 or 3.2) with the bugginess of Python 2's narrow builds. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On 11/25/17 5:05 PM, [email protected] wrote: Hi, my goal is to obtain an interpreter that internally uses UCS-2. Such a simple code should print 65535: import sys print sys.maxunicode This is enabled in Windows, but I want the same in Linux. What options have I pass to the configure script? You say you want Python 3, but you also say you have maxunicode == 65535 on Windows. That must be Python 2. Python 3 always has maxunicode == 1114111. Can you say more about what you need to do? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On 25Nov2017 08:34, rusi wrote: On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: The problem with mixing repository-installed packages with pip-installed packages is that there's always a chance a Debian update will overwrite a pip package, possibly with an older version. Or a pip-installed package might bring in a new version that's not compatible with some debian-installed package, breaking something. On (recent?) debian/ubuntu pip seems to use the 'user-scheme' which means pip runs without sudo and installs in ~/.local/lib So I dont believe literal overwriting would occur Though the point should be made that one should run pip as oneself, and try to avoid doing it as the root user (including avoiding sudo). Many UNIX/Linux/etc users believe "installs" should be done as root, and in this case that is easily avoided, with all its potential for damage to the vendor supplied environment. Cheers, Cameron Simpson (formerly [email protected]) -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > Hi, my goal is to obtain an interpreter that internally > > uses UCS-2. Such a simple code should print 65535: > > > > import sys > > print sys.maxunicode > > > > This is enabled in Windows, but I want the same in Linux. > > What options have I pass to the configure script? > > Why do you want to? What useful value do you have in creating this > buggy interpreter? I see that you are familiar with this bug: https://bugs.python.org/issue13153 And I see it or something very close is still buggy in python 3.5 [No it does not allow me to paste an SMP char but if I open a file containing one it crashes and rather messily — no way to close the idle other than killing the shell] No thats not a diatribe against idle; just that its reasonable to want python to support work-arounds for reasonably common bugs in the current unicode-ecosystem -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sun, Nov 26, 2017 at 3:53 PM, Rustom Mody wrote: > On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: >> On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: >> > Hi, my goal is to obtain an interpreter that internally >> > uses UCS-2. Such a simple code should print 65535: >> > >> > import sys >> > print sys.maxunicode >> > >> > This is enabled in Windows, but I want the same in Linux. >> > What options have I pass to the configure script? >> >> Why do you want to? What useful value do you have in creating this >> buggy interpreter? > > I see that you are familiar with this bug: https://bugs.python.org/issue13153 > > And I see it or something very close is still buggy in python 3.5 > [No it does not allow me to paste an SMP char but if I open a file containing > one it crashes and rather messily — no way to close the idle other than > killing > the shell] > > No thats not a diatribe against idle; just that its reasonable to want python > to support work-arounds for reasonably common bugs in the current > unicode-ecosystem No, that issue is about IDLE (and, AIUI, is actually a Tcl/Tk limitation). I'm talking about how Windows Pythons up to 3.2 could take a single character and treat it as two, or could reverse a string and make it actually not contain code points any more, or get all the subscripts off by one (or more than one). That didn't happen on the Linux builds. They had the lesser problem that all strings consumed large amounts of memory. As of Python 3.3, neither problem exists on either platform. You can't compile them back in. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
26.11.17 01:59, Terry Reedy пише: On 11/25/2017 5:12 PM, Chris Angelico wrote: On Sun, Nov 26, 2017 at 9:05 AM, wrote: Hi, my goal is to obtain an interpreter that internally uses UCS-2. Such a simple code should print 65535: import sys print sys.maxunicode This is enabled in Windows, but I want the same in Linux. What options have I pass to the configure script? You must be trying to compile 2.7. There may be Linux distributions that compile this way. UCS-2 is the default in 2.7. But most Linux distributions build it with UCS-4. -- https://mail.python.org/mailman/listinfo/python-list
