Re: I am out of trial and error again Lists
On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote: On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody wrote: Its generally accepted that side-effecting functions are not a good idea -- typically a function that returns something and changes global state. Only in certain circles. Not in Python. There are large numbers of functions with side effects (mutator methods like list.append, anything that needs lots of state like random.random, everything with external effect like I/O, heaps of stuff), and it is most definitely not frowned upon. In Python 3 (or Python 2 with the future directive), print is a function, print() an expression. It's not semantically a statement. Ok So give me a valid (ie useful) use where instead of the usual l=[1,2,3] l.append(4) we have foo(l.append(4)) -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On Sat, Oct 25, 2014 at 4:55 PM, Rustom Mody rustompm...@gmail.com wrote: So give me a valid (ie useful) use where instead of the usual l=[1,2,3] l.append(4) we have foo(l.append(4)) Given that l.append(4) will always return None, there's not a lot of point passing that return value to something, unless you're doing this inside a lambda or something dumb like that. It won't be Pythonic. Your point? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On 10/24/2014 09:37 AM, Seymore4Head wrote: snip import string Not needed, delete it. def nametonumber(name): lst=[] nx=[] digit=[] Not needed. You create digit as an empty list, them immediately follow by assigning a string to it (NOT a _list_ of characters, but an actual string.) digit=.join(str(i) for i in range(10)) digit is now the _string_ 0123456789. Actually, a direct assignment here would be easier and shorter; digit = 0123456789 for x in name: lst.append(x) lst is now a list of the characters in name. That works, but you can do the same thing with: lst = list(name) for y in (lst): Parentheses not needed. if y in lst(range(1,10)): This is the line the traceback is referring to. lst is a list, but the parentheses tell Python you are trying to call it as a function. That is what the TypeError: 'list' object is not callable means. Also it seems you are now trying to make a list of the digits 1-9 without the zero. Is this what you want? I don't think so, but if that IS what you want you can do it easier with slicing (look it up, VERY useful): (Remember, digit is already a string of the ten digits, with zero as the first character.) if y in digit[1:]: Otherwise if you do want zero included you simply need: if y in digit: #if y in 1234567890: #if y.isdigit(): #if y in digit: All of those should work, with the zero. #if y in string.digits: Ok (I think?), but the string module is effectively obsolete -- most of its capabilities have been replaced with newer, better string methods. It is RARELY useful. I have never used it myself so don't know too much about it. It is definitely not needed here, and is why I suggested deleting the import. nx.append(y) ... -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On 10/24/2014 12:07 PM, Seymore4Head wrote: On Fri, 24 Oct 2014 19:40:39 +0100, Mark Lawrence snip How many more times, state what you expect to happen and what actually happens. doesn't work is useless. Please read this http://sscce.org/ Good suggestion. OK how is this? It doesn't print what I expect. That is NO different from the useless crap you consistently give us! Tell us EXACTLY WHAT YOU EXPECT!! Does it print what you expect? Yes it does. But what I expect is different from what you (erroneously) expect. name=123-xyz-abc for x in name: if x in range(10): x is a character (a one-element string). range(10) is a list of ints. A string will never match an int. BTW, as it is used here, range(10) is for Py2, for Py3 it needs to be list(range(10)). print (Range,(x)) if x in str(range(10)): Once again, find out what str(range(10)) actually is. It is NOT what you think it is. And I'll reiterate what everyone here keeps telling you: USE THE INTERACTIVE MODE to see what really goes on. If you keep resisting this you are making your understanding several hundred times more difficult. print (String range,(x)) Sorry for the harsh tone. I'm old, and the curmudgeon is starting to come out in me. -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On 25/10/2014 03:41, Seymore4Head wrote: On Fri, 24 Oct 2014 19:16:21 -0700, Larry Hudson org...@yahoo.com wrote: On 10/24/2014 07:38 AM, Seymore4Head wrote: snip I do get the difference. I don't actually use Python 2. I use CodeSkulptor. I do have Python 3 installed. Actually I have Python 2 installed but IDLE defaults to Python 3. So it is a pain to actually load Python 2. Exactly HOW are you trying to run Idle? A default install of Py2 and Py3 in Windows should have also installed Idle for each version. In my Win7 system, they are BOTH in the standard menu, you should be able to call up either one. OT: Side comment: I rarely use Windows these days, maybe once every two or three months -- I MUCH prefer Linux. Among other reasons its a far better environment for programming. I only have one (active) system with Windows installed, and two others with Linux only. Actually make that three, if you count my Raspberry Pi. :-) -=- Larry -=- I have a directory of my py files. I right click on one of the py files and open with IDLE Windows XP If I try to open a py file I have for Python 2 it still opens using IDLE 3. I don't have many py 2 files anyway. How about running your Python 2 version of IDLE and opening your files using File-Open or CTRL-O? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
Rustom Mody wrote: On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote: On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody wrote: Its generally accepted that side-effecting functions are not a good idea -- typically a function that returns something and changes global state. Only in certain circles. Not in Python. There are large numbers of functions with side effects (mutator methods like list.append, anything that needs lots of state like random.random, everything with external effect like I/O, heaps of stuff), and it is most definitely not frowned upon. In Python 3 (or Python 2 with the future directive), print is a function, print() an expression. It's not semantically a statement. Ok So give me a valid (ie useful) use where instead of the usual l=[1,2,3] l.append(4) we have foo(l.append(4)) Your question seems to be non-sequitor. To me, it doesn't appear to have any relationship to Chris' comments. But to answer your question, Ruby has mutator methods like list.append return the list being mutated, to make it easy to chain multiple calls: l.append(4).reverse().sort() That would make it easy and convenient to modify a list immediately pass the modified list to a function and embed it in an expression: # Python's way l.append(4) values = [1, 2, foo(l), 3] # Pseudo-Ruby way values = [1, 2, foo(l.append(4)), 3] Languages where all values are immutable *by definition* have to return a new list, since you can't modify the original, hence they too can easily be embedded in an expression. Many people try to write something like this: old_lists = [a, b, c, d] new_lists = [thelist.append(x) for thelist in old_lists if len(thelist) 5] only to be unpleasantly surprised to discover than new_lists now contains None instead of the lists. Having methods return a result rather than behave like a procedure is a valid (i.e. useful) design choice. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On 10/25/14 1:03 AM, Steven D'Aprano wrote:
alister wrote:
On Fri, 24 Oct 2014 10:20:30 -0700, Dan Stromberg wrote:
On Fri, Oct 24, 2014 at 1:38 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
I don't get why that's considered hard to read.
So why is it hard to read when the index is a flag?
value = [f, g][cond]()
[Dan]
It's clear to you, it's clear to me, but is it clear to everyone? I
very much doubt it.
Of course it won't be clear to*everyone* but it should be clear enough to
people who are familiar with standard Python idioms. A concrete example
should be more obvious than the fake example:
title = ('Mr', 'Ms')[person.sex == 'F']
which should be clear to anyone who understands indexing in Python and that
True == 1 and False == 0.
You mention standard Python idioms. I think this style of
conditional-via-indexing is becoming quite uncommon, and is no longer
one of the standard Python idioms. This is now in the category of
outdated hack.
Yes, its meaning is well-defined by the language. But no, its meaning
is not immediately apparent to most of today's Python programmers.
Of course, opinions obviously differ.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Weird connection problem
When I try to access a URL using requests I always get: socket.error: [Errno 104] Connection reset by peer If I try to access the same URL using curl I get no error message instead I get the page. The same result if I use a web browser like Safari. But, if I use python httplib I also get Errno 104. What gives ? Oh, by the way it’s a HTTPS url. — Roland ”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard -- https://mail.python.org/mailman/listinfo/python-list
Re: Weird connection problem
Oh, by the way! To make this more interesting :-/ I saw this behavior on a Linux machine (Ubuntu 14.04 LTS) using Python 2.7.6 if I do the same exercise on a Mac OS X machine also with Python 2.7.6 - no problem what so ever. 25 okt 2014 kl. 08:40 skrev Roland Hedberg roland.hedb...@umu.se: When I try to access a URL using requests I always get: socket.error: [Errno 104] Connection reset by peer If I try to access the same URL using curl I get no error message instead I get the page. The same result if I use a web browser like Safari. But, if I use python httplib I also get Errno 104. What gives ? Oh, by the way it’s a HTTPS url. — Roland ”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard -- https://mail.python.org/mailman/listinfo/python-list — Roland ”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard -- https://mail.python.org/mailman/listinfo/python-list
Re: Weird connection problem
On Sat, Oct 25, 2014 at 9:40 AM, Roland Hedberg roland.hedb...@umu.se wrote: When I try to access a URL using requests I always get: socket.error: [Errno 104] Connection reset by peer If I try to access the same URL using curl I get no error message instead I get the page. The same result if I use a web browser like Safari. But, if I use python httplib I also get Errno 104. What gives ? Oh, by the way it’s a HTTPS url. — Roland Is this for any url or a specific one? -- https://mail.python.org/mailman/listinfo/python-list -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Weird connection problem
It’s a special HTTPS url and searching further it seems to be a SNI problem talked about here: http://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support 25 okt 2014 kl. 08:48 skrev Joel Goldstick joel.goldst...@gmail.com: On Sat, Oct 25, 2014 at 9:40 AM, Roland Hedberg roland.hedb...@umu.se wrote: When I try to access a URL using requests I always get: socket.error: [Errno 104] Connection reset by peer If I try to access the same URL using curl I get no error message instead I get the page. The same result if I use a web browser like Safari. But, if I use python httplib I also get Errno 104. What gives ? Oh, by the way it’s a HTTPS url. — Roland Is this for any url or a specific one? -- https://mail.python.org/mailman/listinfo/python-list -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list — Roland ”Being able to think like a child is an important attribute of being an adult” - Eddie Izzard -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On Sat, Oct 25, 2014 at 5:58 AM, Ned Batchelder n...@nedbatchelder.com wrote: You mention standard Python idioms. I think this style of conditional-via-indexing is becoming quite uncommon, and is no longer one of the standard Python idioms. This is now in the category of outdated hack. I think that's probably true. And even in code written for versions of Python than predate the ternary, I think I've seen the idiom (cond and [if_true] or [if_false])[0] more often than the one being discussed -- perhaps because it more closely resembles the format of the C ternary -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On Sat, Oct 25, 2014 at 12:46 AM, Larry Hudson org...@yahoo.com.dmarc.invalid wrote: name=123-xyz-abc for x in name: if x in range(10): x is a character (a one-element string). range(10) is a list of ints. A string will never match an int. BTW, as it is used here, range(10) is for Py2, for Py3 it needs to be list(range(10)). The last comment is incorrect. You can do membership tests on a Python 3 range object: range(2, 4) range(2, 4) for i in range(5): ... print(i, i in range(2, 4)) ... 0 False 1 False 2 True 3 True 4 False You can also index them: range(50, 100)[37] 87 slice them: range(0, 100, 2)[:25] range(0, 50, 2) get their length: len(range(25, 75)) 50 search them: range(25, 75).index(45) 20 and generally do most operations that you would expect to be able to do with an immutable sequence type, with the exceptions of concatenation and multiplication. And as I observed elsewhere in the thread, such operations are often more efficient on range objects than by constructing and operating on the equivalent lists. -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On 2014-10-24, Denis McMahon denismfmcma...@gmail.com wrote: On Fri, 24 Oct 2014 10:38:31 -0400, Seymore4Head wrote: Thanks everyone for your suggestions. Try loading the following in codeskulptor: http://www.codeskulptor.org/#user38_j6kGKgeOMr_0.py No. We[1] aren't intested in whatever Python-like language is implemented in codeskulptor. [1] I know I'm being a bit presumptuous writing the the plural first person rather than the signular. If you _are_ interested in codeskulptor python then jump in... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Meetup in NYC?
Are there any Python professionals in or around NYC who can meetup for an hour or two to help me with a few things? I've been trying to run various Python scripts for a few months now, and I'm not having any success with this stuff at all. Basically, everything built into Python works perfectly fine for me. However, whenever I try to run something like numpy or beautifulsoup, or anything like that, I have all kinds of errors. If anyone could meet for an hour or two, in a Starbucks, and go through a few examples of Python code, it would be great!! I can take you out for a few beers afterwards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Meetup in NYC?
There's a metope group for Python in NYC and they have project nights/study groups. You should check them out. http://www.meetup.com/nycpython/ On Saturday, October 25, 2014 11:08:31 AM UTC-5, ryguy7272 wrote: Are there any Python professionals in or around NYC who can meetup for an hour or two to help me with a few things? I've been trying to run various Python scripts for a few months now, and I'm not having any success with this stuff at all. Basically, everything built into Python works perfectly fine for me. However, whenever I try to run something like numpy or beautifulsoup, or anything like that, I have all kinds of errors. If anyone could meet for an hour or two, in a Starbucks, and go through a few examples of Python code, it would be great!! I can take you out for a few beers afterwards. -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On Saturday, October 25, 2014 1:15:09 PM UTC+5:30, Steven D'Aprano wrote: Rustom Mody wrote: On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote: On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody wrote: Its generally accepted that side-effecting functions are not a good idea -- typically a function that returns something and changes global state. Only in certain circles. Not in Python. There are large numbers of functions with side effects (mutator methods like list.append, anything that needs lots of state like random.random, everything with external effect like I/O, heaps of stuff), and it is most definitely not frowned upon. In Python 3 (or Python 2 with the future directive), print is a function, print() an expression. It's not semantically a statement. Ok So give me a valid (ie useful) use where instead of the usual l=[1,2,3] l.append(4) we have foo(l.append(4)) Your question seems to be non-sequitor. To me, it doesn't appear to have any relationship to Chris' comments. I am going to leave undisturbed Seymore's thread for whom these nit-picks are unlikely to be helpful Answer in another one -- https://mail.python.org/mailman/listinfo/python-list
Status of side-effecting functions in python
Moved from other (Seymore's) thread where this is perhaps not relevant On Saturday, October 25, 2014 1:15:09 PM UTC+5:30, Steven D'Aprano wrote: Rustom Mody wrote: On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote: On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody wrote: Its generally accepted that side-effecting functions are not a good idea -- typically a function that returns something and changes global state. Only in certain circles. Not in Python. There are large numbers of functions with side effects (mutator methods like list.append, anything that needs lots of state like random.random, everything with external effect like I/O, heaps of stuff), and it is most definitely not frowned upon. In Python 3 (or Python 2 with the future directive), print is a function, print() an expression. It's not semantically a statement. Ok So give me a valid (ie useful) use where instead of the usual l=[1,2,3] l.append(4) we have foo(l.append(4)) Your question seems to be non-sequitor. To me, it doesn't appear to have any relationship to Chris' comments. | Languages like Pascal (many others)... distinguish function which return | results and procedure which do not... | Extract from https://en.wikipedia.org/wiki/Subroutine#Language_support So my point: Whether the language supports it strongly (Pascal' procedures) weakly (C's void functions) more weakly (Python's None returning functions), the beginning programmer needs this concept as a core thinking tool. Pascal makes this easy -- teach the syntax and the concept will get across Python is harder because the concept does not correlate with any specific syntax But its not all that hard unless the teacher is stuck in correlating core concepts and language syntax. A teacher who is so stuck is cheating the student. My version: print may (3) or may not (2) be an expression. Just always consider it as a statement Chris version: print() is an expression. Technically Chris is correct. Is it methodologically/pedagogically it is sound? Consider: From my explanation this: [print(x) for x in [1,2,3]] 1 2 3 [None, None, None] is in Dont Do! category whether python (3) allows it or python 2 doesn't. And you Dont do because print(x) is a statement -- literally in python 2; morally in python 3 And from here its only a small step to why l.append(4) should never be used except as a statement. Python may not literally have Pascal's procedures; they are morally there if you choose to 'believe' in them. How would Chris inculcate avoidance of code-smells like - foo(l.append(4)) - [print(x) for x in [1,2,3]] ? No idea! I dare say: about print I dont know but [foo(x) for x in lst] and foo is used for effect not return-value is a rather common code-smell in my experience -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On Sat, 25 Oct 2014 14:23:44 -0400, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Fri, 24 Oct 2014 10:38:31 -0400, Seymore4Head Seymore4Head@Hotmail.invalid declaimed the following: I do get the difference. I don't actually use Python 2. I use CodeSkulptor. I do have Python 3 installed. Actually I have Python 2 installed but IDLE defaults to Python 3. So it is a pain to actually load Python 2. So don't use Idle... Open up a Windows command shell and invoke Python without giving a script file to execute. C:\Users\Wulfraed\Documentspython ActivePython 2.7.5.6 (ActiveState Software Inc.) based on Python 2.7.5 (default, Sep 16 2013, 23:11:01) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. exit() C:\Users\Wulfraed\Documentspython3 ActivePython 3.3.2.0 (ActiveState Software Inc.) based on Python 3.3.2 (default, Sep 16 2013, 23:11:39) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. exit() C:\Users\Wulfraed\Documents Note that my default Python is still 2.7, but I also have Python 3.3 installed, and can access it using python3 (I can also ensure Python 2.7 by using python2) I tried list(range(10) I thought that would work in Python 3. It didn't. I spent quite a bit of time last night trying to come up with Really? what did it do? SHOW US! C:\Users\Wulfraed\Documentspython3 ActivePython 3.3.2.0 (ActiveState Software Inc.) based on Python 3.3.2 (default, Sep 16 2013, 23:11:39) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. list(range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] print(list(range(10))) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] repr(list(range(10))) '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]' Recall that print is a function in Python 3, so the extra layer of () are required. C:\Users\Wulfraed\Documentspython ActivePython 2.7.5.6 (ActiveState Software Inc.) based on Python 2.7.5 (default, Sep 16 2013, 23:11:01) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. list(range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] print list(range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] print(list(range(10))) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] repr(list(range(10))) '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]' Print doesn't need the (), but they also don't hurt it in Python 2. (still in Py2) range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] xrange(10) xrange(10) print range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] print xrange(10) xrange(10) exit Use exit() or Ctrl-Z plus Return to exit exit() Now Py3 C:\Users\Wulfraed\Documentspython3 ActivePython 3.3.2.0 (ActiveState Software Inc.) based on Python 3.3.2 (default, Sep 16 2013, 23:11:39) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. range(10) range(0, 10) xrange(10) Traceback (most recent call last): File stdin, line 1, in module NameError: name 'xrange' is not defined print(range(10)) range(0, 10) I am not working on that any more. I have my assignment for this week so I am done with busy work. Thanks for all your help -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On Sat, 25 Oct 2014 16:03:16 +1100, Steven D'Aprano wrote: [Alister] I had to mentally step through this before it became apparent what it was doing, can see places where it could be usefull (a switch replacement) but it is not instantly obvious Very little code is instantly obvious. Even when you know what the syntax means, you still have to understand the semantics, and sometimes that's far from obvious. a = value if condition else another Value is instantly obvious (at least to a native English speaker anyway) Ha! And yet people have, and continue to, complain *bitterly* about the non-standard ordering of Python's ternary if, compared to C, standard if...else syntax, and English. Not Me, I don't program i C I don't want to it is too low level fro my liking ( I used to program in assembler for a living) -- You need tender loving care once a week - so that I can slap you into shape. - Ellyn Mustard -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
Of course it won't be clear to *everyone* but it should be clear
enough to people who are familiar with standard Python idioms. A
concrete example should be more obvious than the fake example:
title = ('Mr', 'Ms')[person.sex == 'F']
which should be clear to anyone who understands indexing in Python and
that True == 1 and False == 0.
I consider it an accident of history, and one which should not be
necessary to understand Python code.
In other words, I consider code which exploits the equality of True with
1, or False with 0, is code with a leaky abstraction and should be
fixed.
Although that's probably better written as a dict lookup:
title = {'M': 'Mr', 'F': 'Ms'}[person.sex]
which is then more easily extended to support intersex and
non-traditional[1] gender identities.
It's true that gender is not a binary, but even if it were, this would
be a bad idea.
A schema which blurs the distinction between boolean versus integer is a
code smell: it speaks to the high likelihood that the “flag” really
represents an entity which will soon have more than two states, and
should never have been represented as a boolean.
--
\ “As scarce as truth is, the supply has always been in excess of |
`\ the demand.” —Josh Billings |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On Sat, 25 Oct 2014 15:01:54 +, Grant Edwards wrote: On 2014-10-24, Denis McMahon denismfmcma...@gmail.com wrote: On Fri, 24 Oct 2014 10:38:31 -0400, Seymore4Head wrote: Thanks everyone for your suggestions. Try loading the following in codeskulptor: http://www.codeskulptor.org/#user38_j6kGKgeOMr_0.py No. I wasn't replying to you, I was replying to S4H. We[1] aren't intested in whatever Python-like language is implemented in codeskulptor. However S4H may be, and one thing I can be sure is that if I give him a cs url, he will at least be running the exact same python code I typed in the same python environment, and hence I know what results he should see, namely the same ones I saw. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Status of side-effecting functions in python
On 25.10.2014 19:27, Rustom Mody wrote:
Moved from other (Seymore's) thread where this is perhaps not relevant
On Saturday, October 25, 2014 1:15:09 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote:
On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody wrote:
Its generally accepted that side-effecting functions are not a good
idea -- typically a function that returns something and changes global
state.
Only in certain circles. Not in Python. There are large numbers of
functions with side effects (mutator methods like list.append,
anything that needs lots of state like random.random, everything with
external effect like I/O, heaps of stuff), and it is most definitely
not frowned upon.
In Python 3 (or Python 2 with the future directive), print is a
function, print() an expression. It's not semantically a statement.
Ok
So give me a valid (ie useful) use where instead of the usual
l=[1,2,3]
l.append(4)
we have
foo(l.append(4))
Your question seems to be non-sequitor. To me, it doesn't appear to have any
relationship to Chris' comments.
| Languages like Pascal (many others)... distinguish function which return
| results and procedure which do not...
| Extract from https://en.wikipedia.org/wiki/Subroutine#Language_support
So my point: Whether the language supports it strongly (Pascal'
procedures) weakly (C's void functions) more weakly (Python's None
returning functions), the beginning programmer needs this concept as a core
thinking tool.
Pascal makes this easy -- teach the syntax and the concept will get across
Python is harder because the concept does not correlate with any specific syntax
But its not all that hard unless the teacher is stuck in correlating core
concepts
and language syntax.
A teacher who is so stuck is cheating the student.
My version:
print may (3) or may not (2) be an expression. Just always consider it as a
statement
Chris version: print() is an expression.
Technically Chris is correct. Is it methodologically/pedagogically it is sound?
Consider:
From my explanation this:
[print(x) for x in [1,2,3]]
1
2
3
[None, None, None]
is in Dont Do! category whether python (3) allows it or python 2 doesn't.
And you Dont do because print(x) is a statement -- literally in
python 2; morally in python 3
And from here its only a small step to why l.append(4) should never
be used except as a statement. Python may not literally have Pascal's
procedures;
they are morally there if you choose to 'believe' in them.
How would Chris inculcate avoidance of code-smells like
- foo(l.append(4))
- [print(x) for x in [1,2,3]]
As Chris and Steven have pointed out, picking print() as an example does
not make too much sense since it returns None.
It may be rare to use an expression both for its side-effects and its
return value, but, provided you document the intention appropriately, I
do not see what would generally be wrong with it.
A quick example that's not quite as silly as all your print() ones:
with open('longnumber.txt', 'w') as out:
print(sum(out.write(str(x)) for x in range(100)), 'characters written.')
190 characters written.
--
https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On Fri, 24 Oct 2014 20:15:02 -0400, Seymore4Head wrote: On Wed, 22 Oct 2014 16:30:37 -0400, Seymore4Head Seymore4Head@Hotmail.invalid wrote: name=012 name is a string of 3 characters b=list(range(3)) b is a list of 3 numbers print (name[1]) name[1] is the string 1 print (b[1]) b[1] is the number 1 if name[1] == b[1]: print (Eureka!) This didn't happen else: print (OK, I get it) This happened -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Status of side-effecting functions in python
On Sat, 25 Oct 2014 23:41:52 +0200, Wolfgang Maier wrote: ... It may be rare to use an expression both for its side-effects and its return value ... A lot of concurrency-related operations work that way. In the old days, it was CPU-level Test and Set (or Compare and Set) instructions. These days, we have Python's threading.Lock.acquire. Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On Sat, Oct 25, 2014 at 1:45 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
title = ('Mr', 'Ms')[person.sex == 'F']
which should be clear to anyone who understands indexing in Python and
that True == 1 and False == 0.
I consider it an accident of history, and one which should not be
necessary to understand Python code.
In other words, I consider code which exploits the equality of True with
1, or False with 0, is code with a leaky abstraction and should be
fixed.
I don't like the (a, b)[True] thing, but I use the fact that True is 1
and False is 0 sometimes.
EG, if I have 3 mutually exclusive command line options, I'll do something like:
if option_a + option_b + option_c != 1:
sys.stderr.write('{}: -a, -b and -c are mutually
exclusive\n'.format(sys.argv[0]))
--
https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On 10/25/2014 2:23 PM, Dennis Lee Bieber wrote: On Fri, 24 Oct 2014 10:38:31 -0400, Seymore4Head Seymore4Head@Hotmail.invalid declaimed the following: I do get the difference. I don't actually use Python 2. I use CodeSkulptor. I do have Python 3 installed. Actually I have Python 2 installed but IDLE defaults to Python 3. This is wrong. Pythonx.y runs Idlex.y, not vice versa. Seymore installed some version of Python 3 as default, as he should have, and 'Edit with Idle' opens the default version of Python, with its version of Idle. So it is a pain to actually load Python 2. Not really, neither on linux or Windows. So don't use Idle... Since Seymore analysis is wrong, this advice in not the answer. If he is running on Windows, it is dubious in that the Windows console interpreter is a pain to use. Open up a Windows command shell and invoke Python without giving a script file to execute. C:\Users\Wulfraed\Documentspython python -m idlelib will open the corresponding Idle. So will the Start menu entry or an icon pinned to the taskbar. C:\Users\Wulfraed\Documentspython3 You must have done something extra to make this work on Windows. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Status of side-effecting functions in python
On 10/25/2014 6:22 PM, Dan Sommers wrote: On Sat, 25 Oct 2014 23:41:52 +0200, Wolfgang Maier wrote: ... It may be rare to use an expression both for its side-effects and its return value ... A lot of concurrency-related operations work that way. In the old days, it was CPU-level Test and Set (or Compare and Set) instructions. These days, we have Python's threading.Lock.acquire. list.pop and and related set and dict methods. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: I am out of trial and error again Lists
On 25/10/2014 23:48, Terry Reedy wrote: On 10/25/2014 2:23 PM, Dennis Lee Bieber wrote: On Fri, 24 Oct 2014 10:38:31 -0400, Seymore4Head Seymore4Head@Hotmail.invalid declaimed the following: I do get the difference. I don't actually use Python 2. I use CodeSkulptor. I do have Python 3 installed. Actually I have Python 2 installed but IDLE defaults to Python 3. This is wrong. Pythonx.y runs Idlex.y, not vice versa. Seymore installed some version of Python 3 as default, as he should have, and 'Edit with Idle' opens the default version of Python, with its version of Idle. So it is a pain to actually load Python 2. Not really, neither on linux or Windows. So don't use Idle... Since Seymore analysis is wrong, this advice in not the answer. If he is running on Windows, it is dubious in that the Windows console interpreter is a pain to use. Open up a Windows command shell and invoke Python without giving a script file to execute. C:\Users\Wulfraed\Documentspython python -m idlelib will open the corresponding Idle. So will the Start menu entry or an icon pinned to the taskbar. C:\Users\Wulfraed\Documentspython3 You must have done something extra to make this work on Windows. The Python launcher for Windows should be taken into account here http://legacy.python.org/dev/peps/pep-0397/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
Dan Stromberg drsali...@gmail.com writes:
EG, if I have 3 mutually exclusive command line options, I'll do
something like:
if option_a + option_b + option_c != 1:
sys.stderr.write('{}: -a, -b and -c are mutually
exclusive\n'.format(sys.argv[0]))
That is an excellent illustration of why exploiting this accidental
property of True and False leads to obfuscated code. The above test
gives me no clue that we're operating on boolean values, nor that we're
testing for exclusive options.
The error message bears no obvious relation to the test, and if I was
tracking down that error message I'd have no hint from the code why the
test is written that way. An explanatory comment would be needed, but
that's a strong sign IMO that instead the test should be re-written to
be much more obvious.
--
\ “Never express yourself more clearly than you are able to |
`\ think.” —Niels Bohr |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On Sun, Oct 26, 2014 at 10:53 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Dan Stromberg drsali...@gmail.com writes:
EG, if I have 3 mutually exclusive command line options, I'll do
something like:
if option_a + option_b + option_c != 1:
sys.stderr.write('{}: -a, -b and -c are mutually
exclusive\n'.format(sys.argv[0]))
That is an excellent illustration of why exploiting this accidental
property of True and False leads to obfuscated code. The above test
gives me no clue that we're operating on boolean values, nor that we're
testing for exclusive options.
Would it be more readable thus?
if len([opt for opt in (option_a, option_b, option_c) if opt]) != 1:
Because that's what it's doing. I think treating bools as numbers is
fine. Matter of opinion I guess.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On 26/10/2014 01:01, Chris Angelico wrote:
On Sun, Oct 26, 2014 at 10:53 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Dan Stromberg drsali...@gmail.com writes:
EG, if I have 3 mutually exclusive command line options, I'll do
something like:
if option_a + option_b + option_c != 1:
sys.stderr.write('{}: -a, -b and -c are mutually
exclusive\n'.format(sys.argv[0]))
That is an excellent illustration of why exploiting this accidental
property of True and False leads to obfuscated code. The above test
gives me no clue that we're operating on boolean values, nor that we're
testing for exclusive options.
Would it be more readable thus?
if len([opt for opt in (option_a, option_b, option_c) if opt]) != 1:
Because that's what it's doing. I think treating bools as numbers is
fine. Matter of opinion I guess.
ChrisA
Horrible IMHO, it just doesn't fit in my mind set. Still each to their own.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On Sun, Oct 26, 2014 at 11:09 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: Horrible IMHO, it just doesn't fit in my mind set. Still each to their own. Yeah, the comprehension version is way more explicit (though it probably ought to be a set and a set comp, not a tuple and a list comp), and not as good, IMO. But it explains and justifies the original. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
Ben Finney wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
Of course it won't be clear to *everyone* but it should be clear
enough to people who are familiar with standard Python idioms. A
concrete example should be more obvious than the fake example:
title = ('Mr', 'Ms')[person.sex == 'F']
which should be clear to anyone who understands indexing in Python and
that True == 1 and False == 0.
I consider it an accident of history, and one which should not be
necessary to understand Python code.
In other words, I consider code which exploits the equality of True with
1, or False with 0, is code with a leaky abstraction and should be
fixed.
I suspect that Guido and the core developers disagree with you, since they
had the opportunity to fix that in Python 3 and didn't.
Equating True with 1 and False with 0 is fundamental to many programming
languages, but more importantly Boolean Algebra itself normally identifies
True with 1 and False with 0.
https://en.wikipedia.org/wiki/Boolean_algebra
http://mathworld.wolfram.com/BooleanAlgebra.html
Admittedly this is only a convention, and you're welcome to invent your own
convention, but when doing so you should be aware that Python's convention
is mathematically sound and, well, conventional.
One example of where treating True and False as 1 and 0 is useful is that it
makes counting operations very simple, e.g. counting the number of blank
lines:
sum(not line.strip() for line in lines)
If you reject implicit or explicit bool-to-int conversions:
sum(1 if not line.strip() else 0 for line in lines)
or for compatibility with Python 2.4:
sum({'': 0}.get(line.strip(), 1) for line in lines)
which I consider far less obvious than the straightforward summation of True
values. Sometimes making things *too* abstract is worse than allowing an
abstraction to leak.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
I suspect that Guido and the core developers disagree with you, since
they had the opportunity to fix that in Python 3 and didn't.
That doesn't follow; there are numerous warts in Python 2 that were not
fixed in Python 3. As I understand it, the preservation of bool–int
equality has more to do with preserving backward compatibility.
I agree with the decision, because this isn't an issue which often leads
to *incorrect* code. But I maintain that it's an unfortunate and
needlessly confusing wart of the language.
One example of where treating True and False as 1 and 0 is useful is
that it makes counting operations very simple, e.g. counting the
number of blank lines:
sum(not line.strip() for line in lines)
sum(1 if not line.strip() else 0 for line in lines)
sum({'': 0}.get(line.strip(), 1) for line in lines)
These all look ludicrous and explain nothing about intent, to my
reading. The ‘bool’ type exists precisely because there is a concept to
be represented which is distinct from integers.
Using a sum on non-numeric values just cracks the abstraction open
needlessly. Once I figure out what is going on, I'm left wondering why
the coder chose something so obfuscatory to their intent.
This is short and clear and needs no leaking of the underlying bool
implementation::
len(True for line in lines if line.strip())
which I consider far less obvious than the straightforward summation
of True values.
Why sum them at all? You aren't interested in them as numbers, you're
just asking how many objects meet a criterion. That calls not for ‘sum’,
but ‘len’. There's no need to rely on an underlying ‘int’ operation just
to count objects.
The fact that summing them gives the same answer as simply asking how
many there are, demonstrates that nothing is gained by peeking into the
implementation. The example I give above works exactly as well with no
‘int’ underlying the ‘bool’ type at all.
--
\ “The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything.” —Aahz |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On 10/22/2014 09:46 PM, Gregory Ewing wrote: Chris Angelico wrote: I've seen much MUCH worse... where multiple conditional expressions get combined arithmetically, and then the result used somewhere... In the days of old-school BASIC it was common to exploit the fact that boolean expressions evaluated to 0 or 1 (or -1, depending on your dialect :) to achieve conditional expressions or other tricks. As far as I can tell, no BASIC dialect I've looked at (DOS and Linux worlds only), has ever had any logical operators like AND (), OR (||), and NOT (!). They only appear to have bitwise operators (,|,~ C equivalent). The fact that comparison operators returned 0 and -1 made the bitwise operators function the same as logical. But you can run into trouble if you tried to use a common python idiom like this: x = read_some_lines() 'returns number of lines read, or zero if none are if not x: print (I couldn't read any lines) exit(1) Basically any value other than -1 for x would cause the not x to be true. Off topic, and no matter to python programmers. But for BASIC you need to watch out for this. One BASIC dialect introduced a set of functions, istrue() and isfalse() to convert a non-zero truth value to -1, and any falsish value to zero (like maybe an empty string). That way the bitwise operators would always function as logical operators in a conditional expression. -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
Ben Finney ben+pyt...@benfinney.id.au writes: This is short and clear and needs no leaking of the underlying bool implementation:: len(True for line in lines if line.strip()) Correction:: len([True for line in lines if line.strip()]) -- \ “Our task must be to free ourselves from our prison by widening | `\our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On Sun, Oct 26, 2014 at 12:04 PM, Michael Torrie torr...@gmail.com wrote: But you can run into trouble if you tried to use a common python idiom like this: x = read_some_lines() 'returns number of lines read, or zero if none are if not x: print (I couldn't read any lines) exit(1) Basically any value other than -1 for x would cause the not x to be true. So don't use Python idioms in BASIC. :) Back when I used to write BASIC code, I'd do explicit comparisons with zero for this sort of thing... these days, I'd use Python idioms, but I'd also write Python code :) I think it's indicative that the BASIC code I'm most proud of was consciously getting around language limitations (I wrote a mess of code in assembly language and Q-BASIC to allow my programs to use the mouse), but the Python code I'm most proud of is using the language's strengths. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
On 10/25/2014 07:20 PM, Chris Angelico wrote: So don't use Python idioms in BASIC. :) Back when I used to write BASIC code, I'd do explicit comparisons with zero for this sort of thing... these days, I'd use Python idioms, but I'd also write Python code :) I think it's indicative that the BASIC code I'm most proud of was consciously getting around language limitations (I wrote a mess of code in assembly language and Q-BASIC to allow my programs to use the mouse), but the Python code I'm most proud of is using the language's strengths. Hey I did the same thing in Turbo and then later Power BASIC. I have a soft spot for BASIC, and now with FreeBASIC releasing their 1.0 release (object-oriented capabilities and the works), I revisited a bit of my BASIC past. Translated a few programs from Turbo and Power BASIC into the more modern FreeBASIC dialect. But now that that's done, it's back to Python, where I'm going to stay! Python reminds me of the best BASIC had to offer plus a whole lot more. -- https://mail.python.org/mailman/listinfo/python-list
Re: (test) ? a:b
Ben Finney wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
I suspect that Guido and the core developers disagree with you, since
they had the opportunity to fix that in Python 3 and didn't.
That doesn't follow; there are numerous warts in Python 2 that were not
fixed in Python 3. As I understand it, the preservation of bool–int
equality has more to do with preserving backward compatibility.
On reviewing PEP 285, I think it is safe to say that Guido *explicitly*
wants bools to be ints, not just for backwards compatibility:
4) Should we strive to eliminate non-Boolean operations on bools
in the future, through suitable warnings, so that for example
True+1 would eventually (in Python 3000) be illegal?
= No.
There's a small but vocal minority that would prefer to see
textbook bools that don't support arithmetic operations at
all, but most reviewers agree with me that bools should always
allow arithmetic operations.
http://legacy.python.org/dev/peps/pep-0285/
I agree with the decision, because this isn't an issue which often leads
to *incorrect* code. But I maintain that it's an unfortunate and
needlessly confusing wart of the language.
That puts you in the small but vocal minority :-)
One example of where treating True and False as 1 and 0 is useful is
that it makes counting operations very simple, e.g. counting the
number of blank lines:
sum(not line.strip() for line in lines)
sum(1 if not line.strip() else 0 for line in lines)
sum({'': 0}.get(line.strip(), 1) for line in lines)
These all look ludicrous and explain nothing about intent, to my
reading.
[...]
I'm left wondering why
the coder chose something so obfuscatory to their intent.
Ludicrous and obfuscatory. They're awfully strong words.
Do you really not see the connection between counting and summing? If so,
that would put you in a truly small minority. The connection between adding
and counting has been known to Western mathematics since at least the
ancient Greeks, if not even earlier, and we teach it to school children. If
you have three apples, and I have two apples, then in total we have (count
the apples: one two three, four five) five apples. Pre-schoolers learn
this. I'm sure it's not too difficult for programmers.
This is short and clear and needs no leaking of the underlying bool
implementation::
len(True for line in lines if line.strip())
I see that in a later email you discovered your unfortunate bug in this, and
corrected it to this:
len([True for line in lines if line.strip()])
Alas, you missed the bigger bug: I'm counting *blank lines*, not non-blank
lines. You need a `not` in there.
You mentioned intent before. I wonder what your intention is, to needlessly
build a potentially gigantic list of identical values, only to then throw
the list away. Could be worse; you might have written
[True for line in lines if not line.strip()].count(True)
Since the list items exist only to be counted, the actual item used makes no
difference. You could use any value at all, or even a different value each
time:
len([random.random() for line in lines if not line.strip()])
What is your reason for the choice of True as the tally marker? It doesn't
clarify your intent, or make it more obvious that you're counting the
number of non-empty lines. If you wanted to suggest a tally:
len(['/' for line in lines if not line.strip()])
at least looks like a tally: makes four. Using a bool doesn't make this
any clearer, and you don't even have the excuse that it's efficient,
because it isn't.
Let's get rid of the list comp and write a straightforward translation:
temp = []
for line in lines:
if not line.strip():
temp.append(True)
result = len(temp)
del temp
I don't consider that sensible code at all. Why waste time building the
temporary list when all we want is a counter?
result = 0
for line in lines:
if not line.strip():
result += 1
which can be simplified to:
result = 0
for line in lines:
result += not line.strip()
I agree with you that this breaks the abstraction bools are abstract
enumerations, not ints, but that abstraction is not part of Python. If I
objected to code like this:
types = [int, str, list, dict]
for t in types:
do_something_with(t)
on the basis that we shouldn't treat types as values, because that breaks
the abstraction that types are not values, they're a different kind of
thing known only to the compiler (as in Java), I expect that you would
have no hesitation in telling me that my objection was invalid. Making
types be non-values may, or may not, be a reasonable programming model, but
it's not Python's programming model. In Python, types are themselves
objects and first-class values. Objecting to Python code because it
violates a norm from some other language is, frankly, silly.
The abstraction bools are abstract enumerations different from
Re: (test) ? a:b
On Sun, Oct 26, 2014 at 3:15 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Since the list items exist only to be counted, the actual item used makes no difference. You could use any value at all, or even a different value each time: len([random.random() for line in lines if not line.strip()]) What is your reason for the choice of True as the tally marker? It doesn't clarify your intent, or make it more obvious that you're counting the number of non-empty lines. Personally, I'd use the original value. When you're counting something, it's common to count that thing, rather than some stand-in. len([line for line in lines if not line.strip()]) But that's no better than anything else. The only significance is that it feels more like counting a filtered portion of the list. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue22725] improve documentation for enumerate() (built-in function)
Van Ly added the comment: I don't want to argue. Ask a 12-year old and their English teacher, Does the second sentence qualify as gobbledygook even if it is technically correct and complete and not verbose? To be constructive and take on what has been said, an iteration on improving the wording: -- improve wording as follows: enumerate(iteratable, start=0) Accepts an iteratable[typo for iterable?] and returns an iterator, a special case 'enumerate object'. The method iterator.next() returns a tuple which pairs an index counter with the object at the index in iterable. led = ['red', 'green', 'blue'] led = ['red', 'green', 'blue'] iter = enumerate(led) iter = enumerate(led) iter.next() iter.next() (0, 'red') iter.next() iter.next() (1, 'green') iter.next() iter.next() (2, 'blue') # While enumerate does not return a list of pairs, # it is easy to collect the pairs and construct a list as follows list(enumerate(led)) list(enumerate(led)) [(0, 'red'), (1, 'green'), (2, 'blue')] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22722] inheritable pipes are unwieldy without os.pipe2
STINNER Victor added the comment: os.dup2() is really a special case for inheritable file descriptors. See the PEP 446. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22722 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Ethan Furman added the comment: rdm was not asking for an argument, he was asking for a more detailed explanation of what was confusing. Your initial response lacked courtesy and respect, and is not appreciated. The rest of your reply was much better. Next time, please skip the non-constructive portion. -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Van Ly added the comment: Understood. I felt the problem was self evident with sequence must be a sequence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22672] float arguments in scientific notation not supported by argparse
Jacopo Nespolo added the comment: Ned Deily: I don't quite know how to use unittest, but I'll try to look into it. paul j3: There I proposed leaving '_negative_number_matcher' unchanged, but only use it to set '_has_negative_number_optionals'. I don't know argparse internals but, if I understand your argument, I think you still need a '_negative_number_matcher' capable of correctly match any negative number in any form, including scientific notation, complex j, etc.. If this is the case, then, the matcher could be simplified to something like '^-\d+|^-.\d+' (notice $ removed from current regex) which would only signal that something that starts like a negative number is present. Then one could use complex() or float() or whatever, to check that that's actually the case. I would still expect an exception to be raised if, say, I specify type=float and then a complex value is passed as an argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Georg Brandl added the comment: I felt the problem was self evident with sequence must be a sequence. The two words are not used in the same sense: the first names the argument of the function, the second is one of several possible object types you can pass for that argument. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Van Ly added the comment: sequence must be a sequence The subtle minutiae of aficionados necessary to interpret the meaning of those two words in their distinct relation is opaque to a new comer and doesn’t serve the widest possible audience usefully to get the job done quick. The second placed sense has a range of possibility narrower than iterable as has been said, all sequences are iterables but not all iterables sequences. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
Serhiy Storchaka added the comment: Hmm... is it important? Not more than sorting pprint output at all. This looks low priority issue to me, but the fix looks pretty easy. Here is a patch. I hope Raymond will make a review, may be I missed some details. -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file37011/pprint_safe_key.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Van Ly added the comment: The first mention of iterator should link to 'glossary.html#term-iterator'. There is a builtin iter() function. This may cause confusion in earlier suggested inline sample code. -- Use the following inline sample code -- in place of 'iter = enumerate(led)'to avoid confusion with iter() builtin: led = ['red', 'green', 'blue'] iterator = enumerate(led) try: while True: print iterator.next() except StopIteration: print 'End of iterator has been reached.' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22678] An OSError subclass for no space left on device would be nice
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22678 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22705] Idle extension configuration: add option-help option
Saimadhav Heblikar added the comment: Attached is a patch which attempts to display help text using a ToolTip. The additional requirement is that for entry 'name', there be another entry have a 'name_help' in the config-extensions.def(easier to see the file to understand what I mean). A few changes were required in ToolTip.py to adjust the delay in millisecond value. Note : In the current patch, I have added demo help string only for CodeContext and AutoComplete. -- keywords: +patch Added file: http://bugs.python.org/file37012/issue22705-v1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22705 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22237] sorted() docs should state that the sort is stable
Stéphane Wirtel added the comment: ping. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22237 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12916] Add inspect.splitdoc
Stéphane Wirtel added the comment: @berker.peksag Could you review the last patch? and keep me informed? Thanks, -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22711] Distribution guide should link directly to distutils setuptools API references
Nick Coghlan added the comment: Since the community has been so successful at shouting down most previous attempts at fundamental Python packaging ecosystem improvements, I am extraordinarily hostile to anything that even hints at attempting to do so again. I interpreted the proposal originally put forward in this issue as just such an attempt. Specifically, it reads to me as ah, this link was too hard to find, despite still being the top link when searching 'python distutils', let's revert all the docs changes, so newcomers to Python can go back to being just as lost and confused as they were before PEP 453 was accepted and implemented. The legacy docs are not better than packaging.python.org or the setuptools docs - they are actively misleading in several respects, and extracting useful information from them requires that you already be an expert in the Python packaging ecosystem so you can successfully figure out which bits you need to ignore and which bits provide relevant information not yet covered anywhere else. However, on rereading https://docs.python.org/3/distributing/, I agree it should at least point readers directly at the package API references for both distutils and setuptools. At the moment, even the existing inline references aren't hyperlinked. The distutils landing page should also point readers directly at the setuptools docs, rather than requiring an indirection via the packaging user guide. -- title: legacy distutils docs better than packaging guide - Distribution guide should link directly to distutils setuptools API references ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
Serhiy Storchaka added the comment: And here is alternative patch if the first patch is not correct. It is more complicated and I suppose is less efficient in common case. -- Added file: http://bugs.python.org/file37013/pprint_safe_key_alt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18216] gettext doesn't check MO versions
Aaron Hill added the comment: Is there anything that needs to be changed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22711] Distribution guide should link directly to distutils setuptools API references
Roundup Robot added the comment: New changeset c46953d76d4c by Nick Coghlan in branch '3.4': Issue #22711: improve links in new distribution docs https://hg.python.org/cpython/rev/c46953d76d4c New changeset cbb9efd48405 by Nick Coghlan in branch 'default': Merge issue #22711 from 3.4 https://hg.python.org/cpython/rev/cbb9efd48405 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22711] Distribution guide should link directly to distutils setuptools API references
Nick Coghlan added the comment: I added several previously missing hyperlinks, together with a short description of some key setuptools benefits in the distutils landing page. Let me know if you had more than that in mind. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22711] Distribution guide should link directly to distutils setuptools API references
Antoine Pitrou added the comment: Le 25/10/2014 15:37, Nick Coghlan a écrit : Since the community has been so successful at shouting down most previous attempts at fundamental Python packaging ecosystem improvements, I am extraordinarily hostile to anything that even hints at attempting to do so again. You're saying that to the guy who wanted distutils2 to stay in the stdlib. I added several previously missing hyperlinks, This is good. Thank you Nick! -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22711] Distribution guide should link directly to distutils setuptools API references
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22711] Distribution guide should link directly to distutils setuptools API references
Nick Coghlan added the comment: Also, my apologies for overreacting - I interpreted the suggestion in the worst possible light, which you definitely didn't deserve. Actually going back and rereading the guide with the benefits of a few months distance from originally writing it made the problems you encountered *much* clearer to me - the relevant links were there on the distutils landing page, but that page itself wasn't easily reachable from the top level navigation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Nick Coghlan added the comment: If you want the simple model, there's nothing to change (except perhaps documentation), as that's the way things work today. subtest support also makes it much easier to factor out common assertions without relying on the setUp/tearDown protocol, so I'd be OK with explicitly declaring having common assertions in those methods to be an abuse of the protocol. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
R. David Murray added the comment: I think you misunderstand the purpose of the documentation you are suggesting modifying. It is a *reference guide*, and as such it needs to be technically precise and *must* correctly use the jargon of the language. Especially since it also functions as the reference guide for people who implement new versions of Python, and need to know what behavior of things like 'enumerate' they need to reproduce. That said, we also prefer the reference docs to be clear and understandable to someone who is a relative beginner, as long as we don't lose precision in doing so. Thus the glossary and the glossary links, so yes it would be a good idea to add those. I did indeed misspell iterable. Your sentence is still incorrect...items returned by an iterator do not necessarily have an index (that is, you can't say myiterator[3] in the general case). So, if I understand correctly, your difficulty was the confusion between the argument name *sequence* and the technical term ``sequence`` (referring to a Python object type). I agree that that makes things confusing. It would be better if the argument were named *iterable*, but we can't really change it at this point for backward compatibility reasons. Maybe if we rearrange things a bit we can make it clearer. How about this: Return an enumerate object which when iterated[link to glossary] yields a two-tuple for each element in *sequence*, each tuple consisting of the sequence number of the element (beginning with *start*, which defaults to 0) paired with the element itself. *sequence* must be a sequence, an iterator, or some other object which supports iteration. That moves the distracting precise definition of *sequence* to the end, after you've already grasped what the function does. You will note that I've also dropped the reference to next; that is implicit in the mention of when iterated, since it is an integral part of the iteration protocol. IMO it is a distraction to mention next in this context. It confuses the beginner and isn't needed by the expert. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22716] Add reference to the object missing an attribute to AttributeError
flying sheep added the comment: No, this is about the object which misses an argument, not the attribute name. But thanks for the pointer: one combined fix for both would be the smartest thing to do. -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
R. David Murray added the comment: Oh, now I understand what the issue is. It never even *occurred* to me that someone might put assertions in setUp or tearDown. So, yeah, count me in on considering that an abuse of the protocol :) (If I want to factor out common assertions, and I do it a lot, I put them in a helper method and call it explicitly.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22716] Add reference to the object missing an attribute to AttributeError
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: duplicate - stage: resolved - superseder: Add an 'attr' attribute to AttributeError - versions: +Python 3.5 -Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Nick Coghlan added the comment: Heh, yeah, I've written *many* check_* methods in my life - I just hadn't made the link between that practice, and this suggestion. I think that switches me firmly to the don't change the behaviour camp. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value
Changes by Philip Semanchuk osvens...@users.sourceforge.net: -- nosy: +osvenskan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20584 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22716] Add reference to the object missing an attribute to AttributeError
Serhiy Storchaka added the comment: See also PEP 473. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22727] Improve benchmarks precision
New submission from Antoine Pitrou: This patch tries to improve precision of benchmarks in the benchmark suite by two measures: - select the best timer for the pair of interpreters (i.e. perf_counter() if possible) - make hashing deterministic to avoid fluctuations between runs -- components: Benchmarks files: precision.patch keywords: patch messages: 230011 nosy: brett.cannon, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Improve benchmarks precision type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37014/precision.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Changes by Georg Brandl ge...@python.org: -- nosy: -georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22725] improve documentation for enumerate() (built-in function)
Ethan Furman added the comment: +1 for rdm's change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22727] Improve benchmarks precision
Georg Brandl added the comment: LGTM. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22727] Improve benchmarks precision
Antoine Pitrou added the comment: Pushed in dc7d29be5a9e. -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22728] Deprecate spurious benchmarks
New submission from Antoine Pitrou: iterative_count and threaded_count are really uninteresting benchmarks, inherited from Dave Beazley's GIL experiments. I suggest to deprecate them and remove from the all and 2n3 sets. Patch attached. -- components: Benchmarks files: deprecated.patch keywords: patch messages: 230015 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: Deprecate spurious benchmarks type: enhancement Added file: http://bugs.python.org/file37015/deprecated.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22728 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22728] Deprecate spurious benchmarks
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22728 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22729] `wait` and `as_completed` depend on private api
New submission from Ben Mather: Adds `remove_done_callback` to `Future` object, removes `_waiters` attribute, and re-implements `wait` and `as_completed` using callbacks. This makes it possible to extend or replace `Future` without having to mimic its private `_waiters` interface. Currently waiters and callbacks are triggered at different points after a cancel (waiters in `set_condition_and_notify_cancel` and callbacks in `cancel`.) This is a problem as it means that implementing `wait` and `as_completed` using `add_done_callback` will result in a behaviour change unless the behaviour of `add_done_callback` is changed instead. I don't believe the current behaviour is as documented anyway so I'm not sure if this is a problem. See issue 22630. I am a little uncertain about the O(n) implementation of `remove_done_callback` but can't imagine a situation where it would be a problem. -- components: Library (Lib) files: non-magic-waiters.patch keywords: patch messages: 230016 nosy: bwhmather priority: normal severity: normal status: open title: `wait` and `as_completed` depend on private api type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37016/non-magic-waiters.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22729 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22630] `concurrent.futures.Future.set_running_or_notify_cancel` does not notify cancel
Ben Mather added the comment: Have uploaded patch to re-implement `wait` and `as_completed` using callbacks. See issue 22729. Sorry for sitting on it for so long. -- Added file: http://bugs.python.org/file37017/non-magic-waiters.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22630 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22672] float arguments in scientific notation not supported by argparse
paul j3 added the comment:
Patch tests are added to an existing 'Lib/test/test_argparse.py' file. I use
existing test cases as a pattern any new tests.
-
Your test file runs fine with the patch I proposed for Issue 9334.
-
The argparse code uses '_negative_number_matcher' for 2 purposes
1) to test whether an option_string looks like a negative number, and set the
'self._has_negative_number_optionals' attribute.
parser.add_argument('-2')
parser.add_argument('-1.234')
2) to test whether an argument string (an element of sys.argv) looks like one
of those option_strings, or is an argument (positional or argument to your
'-a').
The 'type' in for your '-a' argument is separate issue. That is used convert a
string to a number, float, complex or what ever, and raise an error it if can't
do so.
In your case './test.py -a -1e5' fails because '-1e5' fails the 2nd test, and
thus is not recognized as an argument to '-a'. Understanding the details of
this requires digging into the logic of the _parse_optional() method.
'./test.py -a-1e5' or './test.py -a=-1e5' work because the number is correctly
recognized as an argument.
For issue 9334 I looked at generalizing '_negative_number_matcher' as you did.
But unless you want to use something like:
parser.add_argument('-1.2e-34')
and set the 'self._has_negative_number_optionals' to '[True]', the matcher
doesn't need to be more general.
It's only the test in '_parse_optional()' that needs to be generalized to
handle scientific and complex notation. And for that I figured that wrapping
'complex()' in a 'try' block was just as general and reliable as a complicated
're' pattern. At least that was my claim in issue 9334, and I haven't gotten
feedback on that.
I'd suggest reading the 9334 discussion, and testing that patch. That patch
includes some tests for scientific and complex numbers.
That issue and patch also adds a 'args_default_to_positional' parameter. I
wonder if the two changes should be put in separate patches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22672
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22727] Improve benchmarks precision
Serhiy Storchaka added the comment: For more precise results it may be worth to run interpreters several times with random hash seed and then select the best time. Different interpreters can have different effect on the same seed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22727] Improve benchmarks precision
Antoine Pitrou added the comment: You thereotically need 2**63 runs to select the best answer, though. You don't know how the distribution of hash seeds can influence the results, which means mere sampling may not be sufficient. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22727 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x
Jason R. Coombs added the comment: This issue has been monkeypatched by setuptools for 7 years: https://bitbucket.org/pypa/setuptools/commits/4556f9d08ef7 -- assignee: tarek - components: -Distutils2 nosy: +dstufft, jason.coombs versions: +Python 3.4, Python 3.5 -3rd party, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22729] `wait` and `as_completed` depend on private api
Changes by Ned Deily n...@acm.org: -- nosy: +bquinlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22729 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22261] Document how to use Concurrent Build when using MsBuild
Roundup Robot added the comment: New changeset f35403bf8c91 by Zachary Ware in branch 'default': Issue #22261: Add a note to PCbuild\readme.txt about MSBuild switches. https://hg.python.org/cpython/rev/f35403bf8c91 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22261 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22261] Document how to use Concurrent Build when using MsBuild
Zachary Ware added the comment: I finally made it back to this and committed a tweaked version of your patch. Thanks for the report and patch! -- resolution: - fixed stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22261 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
