[issue7180] "pydoc -k" can generate AttributeError on Mac OS X

New submission from Kevin Grant : Running "pydoc -k ..." with a query string will end with a Python AttributeError while looking for Carbon.File.FSSpecType. I was using /usr/bin/pydoc on Mac OS X Snow Leopard, which is from Python 2.6.1. It appears that any query will produce a similar error,

[issue7179] Unportable test(1) construct

Changes by Ned Deily : -- assignee: -> ronaldoussoren components: +Macintosh nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-b

[issue7119] email: msg.items() returns different values before and after msg.as_string()

Changes by R. David Murray : -- assignee: georg.brandl -> r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue7179] Unportable test(1) construct

Thomas Klausner added the comment: That's against python-2.6.3. I see that Misc/build.sh automagically linked from this bug report doesn't have this problem any longer (though the other file still does). -- ___ Python tracker

[issue7179] Unportable test(1) construct

New submission from Thomas Klausner : Mac/BuildScript/scripts/postflight.patch-profile and Misc/build.sh contain the unportable bash(1) "==" comparison operator for test(1). It is not supported by most other shells or even test(1) from GNU coreutils. Please use "=" instead. -- components

[issue7119] email: msg.items() returns different values before and after msg.as_string()

R. David Murray added the comment: Thinking about this further, it seems to me that it is in fact more important that turning a message into a string produces the same result no matter how many times it is called on the same (otherwise unmutated) object than that it avoid mutating the object tre

[issue1722344] Thread shutdown exception in Thread.notify()

Antoine Pitrou added the comment: Patch was committed in trunk, py3k and 3.1. Waiting for 2.6 to be unfrozen before I commit it there too. -- stage: commit review -> committed/rejected status: open -> pending versions: -Python 2.7, Python 3.1, Python 3.2 __

[issue7178] open function's buffering parameter is not completely doc'ed

Benjamin Peterson added the comment: Fixed in r75572. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue6845] Restart support in binary upload for ftplib

Antoine Pitrou added the comment: > I think that a non-digit REST argument is an error. But I've tested some > ftp servers and they don't return an error code, they just set REST to 0 > and return some OK code. Finally, ftplib doesn't check that, so if > someone accidentally passes a non-digit a

[issue7178] open function's buffering parameter is not completely doc'ed

New submission from kuhnsjohn : it says: "Pass 0 to switch buffering off (only allowed in binary mode), 1 to set line buffering, and an integer > 1 for full buffering." The last section should say something like: "and an integer > 1 to specify the buffer size for full buffering." -- ass

[issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux

Martin v. Löwis added the comment: I'm not sure that changing this would do any good. Applications may rely on the status quo, so I fail to see the point in breaking them. -- ___ Python tracker

[issue7170] subclasses of (some) built-in types are not weakref-able

Daniel Stutzbach added the comment: That's fair. I suggest the following change: current text: "Several built-in types such as list and dict do not directly support weak references but can add support through subclassing:" new text: "Several built-in types such as list and dict do not directl

[issue7177] Unclear warning for subprocess.call

New submission from Christopher Jefferson : I wandered across subprocess.call as it was mentioned as a replacement for os.system. The following large warning is attached to it: Warning Like Popen.wait(), this will deadlock if the child process generates enough output to a stdout or stderr pi

[issue7176] sum() doesn't work for lists.

Raymond Hettinger added the comment: One use of the start argument is used to specify an initial zero/metpy value for the summation: 0 or 0.0 or Decimal(0) or []. BTW, sum() isn't a good technique for concatenating lists. Instead use something like: result = [] for seq in data:

[issue7176] sum() doesn't work for lists.

Björn Augustsson added the comment: Er, that's fairly weird... Couldn't it do eg "type(first argument)", and if it's a list, replace the 0 with []? What's the second argument's use anyway? s = sum([1,2,3,4]) + 3 seems a lot clearer than s = sum([1,2,3,4], 3) and those seem to be equivalen

[issue6845] Restart support in binary upload for ftplib

Giampaolo Rodola' added the comment: The patch looks good to me. Only two little remarks: 1: I'd create two new separate tests rather than appending them to existent ones. 2: > self.client.retrbinary('retr', received.append, rest=str(rest)) str() should be useless here. > According to the RF

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Marc-Andre Lemburg added the comment: Tarek Ziadé wrote: > > Tarek Ziadé added the comment: > > I like ~/.python very much too (that was my initial proposal IIRC). +1 on that name as well. One thing to note though: it is well possible that a user uses multiple Python versions. With just on

[issue6845] Restart support in binary upload for ftplib

Pablo Mouzo added the comment: I think that a non-digit REST argument is an error. But I've tested some ftp servers and they don't return an error code, they just set REST to 0 and return some OK code. Finally, ftplib doesn't check that, so if someone accidentally passes a non-digit argument it

[issue1722344] Thread shutdown exception in Thread.notify()

Antoine Pitrou added the comment: Ok, I'll do it then! -- assignee: -> pitrou ___ Python tracker ___ ___ Python-bugs-list mailing

[issue1722344] Thread shutdown exception in Thread.notify()

Adam Olsen added the comment: Nope, no access. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Tarek Ziadé added the comment: I like ~/.python very much too (that was my initial proposal IIRC). I guess the best way to add this support is to provide a new api in site.py, that returns this folder. Distutils can move pypirc and distutils.cfg file there. Now for the global distutils.cfg,

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Antoine Pitrou added the comment: > The distutils.cfg file is located in the distutils package itself ! > > So the target is ~/.local/pythonX.X/site-packages/distutils/distutils.cfg Ah, that's horrible. -1 to that. Configuration files should be easily findable by skimming through the dot-files

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Tarek Ziadé added the comment: > Well, that makes it the user-specific equivalent of /usr or /usr/local. > Do you put your configuration files in /usr/local ? > Why put them in .local ? The distutils.cfg file is located in the distutils package itself ! So the target is ~/.local/pythonX.X/sit

[issue6845] Restart support in binary upload for ftplib

Antoine Pitrou added the comment: According to the RFC, the argument to REST can be any string of printable characters. However, does it happen for clients to put non-digits in there? (that is, are there any implementations where the argument to REST is something else than the byte offset from t

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

R. David Murray added the comment: +1 to what Antoine said. -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list maili

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Antoine Pitrou added the comment: I've read the thread now and I think the original proposal of having a ~/.python was more sensible and more user-friendly. -- ___ Python tracker ___

[issue1722344] Thread shutdown exception in Thread.notify()

Antoine Pitrou added the comment: The patch looks good to me. And since Py_Finalize() claims to "destroy all sub-interpreters" and "free all memory allocated by the Python interpreter", I guess your approach makes sense. Can you commit? -- resolution: -> accepted stage: patch review ->

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Antoine Pitrou added the comment: > That's what is returned by site.getuserbase() > > (which uses PYTHONUSERBASE, and defaults to ~/.local) Well, that makes it the user-specific equivalent of /usr or /usr/local. Do you put your configuration files in /usr/local ? Why put them in .local ? > PY

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Tarek Ziadé added the comment: That's what is returned by site.getuserbase() (which uses PYTHONUSERBASE, and defaults to ~/.local) PYTHONUSERBASE is the root of Python user-specific paths so it makes sense to have all Python related files in there. This came up with the discussion we had with

[issue6845] Restart support in binary upload for ftplib

Changes by Antoine Pitrou : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux

Antoine Pitrou added the comment: x86-64 is now the common name for the 64-bit instruction set implemented by mainstream AMD and Intel processors. Even on the AMD web site, "x86-64" shows up more often than "AMD64" (says Google). -- nosy: +pitrou ___

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

Antoine Pitrou added the comment: Why is this? .local/ contains machine-installed files while .pydistutils.cfg is edited by the user. -- nosy: +pitrou ___ Python tracker ___

[issue7048] decimal.py: logb: round the result if it is greater than prec

Mark Dickinson added the comment: Sorry; ignore that last. I was confused by the fact that the _check_nans call came before the 'if context is None' test. But _check_nans deals correctly with a context of None, so logb is fine. -- ___ Python tra

[issue7048] decimal.py: logb: round the result if it is greater than prec

Mark Dickinson added the comment: I just want to note another problem with logb: it doesn't use the correct context when processing NaNs. This needs a test and a fix. -- ___ Python tracker __

[issue7176] sum() doesn't work for lists.

Mark Dickinson added the comment: To sum lists, you need to supply a second argument to sum: >>> sum([[1, 2], ['x', 'y']], []) [1, 2, 'x', 'y'] The default value of the second argument is 0, which is why you're seeing the TypeError. -- nosy: +mark.dickinson resolution: -> invalid st

[issue7176] sum() doesn't work for lists.

New submission from Björn Augustsson : Summary: "sum()" doesn't work on lists, even though the docs says it should. The docs say: "Note that sum(range(n), m) is equivalent to reduce(operator.add, range(n), m)" That's not true. import operator a=[1,2] b=["x",

[issue7099] Decimal.is_normal should return True even for numbers with exponent > Emax

Mark Dickinson added the comment: Fixed in r75561 (trunk), r75662 (py3k) and r75663 (release31-maint). release26-maint is still frozen; leaving open for the backport. -- resolution: -> fixed versions: -Python 2.7, Python 3.1, Python 3.2 ___ Python

[issue6672] Add Mingw recognition to pyport.h to allow building extensions

Jan Schlüter added the comment: Hello! Thanks, you're right. I have created a patch against the latest SVN revision (75557) of branches/release26-maint/Include/pyport.h. The patch also applies fine to trunk/Include/pyport.h. As it applies to both versions, I have created the patch directly fr

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

New submission from Tarek Ziadé : [.]pydistutils.cfg will be deprecated in favor of a single "distutils.cfg", located in .local/ alongside the files added for example by the per user-site packages. -- assignee: tarek components: Distutils messages: 94272 nosy: tarek priority: normal seve

[issue7174] modeule: queue class: PriorityQueue

R. David Murray added the comment: In python3 (unlike 2) objects are by default unorderable. You'll need to define an ordering for your objects in order to use them in a PriorityQueue, whether or not they are inside a tuple. -- nosy: +r.david.murray priority: -> normal resolution: ->

[issue7174] modeule: queue class: PriorityQueue

New submission from Andrew Shuiu : Puting 2 tuples like (100, data1), (100, data2) in a PriorityQueue generates an builtins.TypeError: unorderable types: data1 < data2 Code which generates error: theQueue.put((100, object1()),True) theQueue.put((100, object1()),True) Snippet from error: builtin

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: I should add that the crash doesn't necessarily happen during the first test run, which also converts the Cython source to Py3 using 2to3. However, once that's done, running the test a second time crashes reliably. -- ___

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

New submission from Stefan Behnel : Running the Cython compiler under Python 3.1.1 and 3.2 (SVN) corrupts PyThreadState->exc_value by leaving a dead reference. Printing the value then leads to a crash. This bug is about plain Python code, no Cython built extension modules involved. Steps to rep