Re: How to get the realpath of a symbolic link?
Peng Yu wrote:
I find the following two files that define realpath. But I don't find
'realpath' in os.py. I looked at 'os.py'. But I don't understand how
the function realpath is introduced in the name space in os.path.
Would you please let me know?
gfind . ! -path '*backup*' -name *.py -type f -exec grep -n def
realpath {} \; -printf %p\\n\\n
193:def realpath(path):
./macpath.py
345:def realpath(filename):
./posixpath.py
That is where realpath is.
--
http://mail.python.org/mailman/listinfo/python-list
Re: import bug
En Sat, 31 Oct 2009 12:12:21 -0300, kj no.em...@please.post escribió: I'm running into an ugly bug, which, IMHO, is really a bug in the design of Python's module import scheme. The basic problem is that the import scheme was not designed in advance. It was a very simple thing at first. Then came packages. And then the __import__ builtin. And later some import hooks. And later support for zip files. And more import hooks and meta hooks. And namespace packages. And relative imports, absolute imports, and mixed imports. And now it's a mess. Consider the following directory structure: [containing a re.py file in the same directory as the main script] If I now run the innocent-looking ham/spam.py, I get the following error: % python26 ham/spam.py Traceback (most recent call last): [...] File /usr/local/python-2.6.1/lib/python2.6/string.py, line 116, in __init__ 'delim' : _re.escape(cls.delimiter), AttributeError: 'module' object has no attribute 'escape' My sin appears to be having the (empty) file ham/re.py. So Python is confusing it with the re module of the standard library, and using it when the inspect module tries to import re. Exactly; that's the root of your problem, and has been a problem ever since import existed. En Sat, 31 Oct 2009 13:27:20 -0300, kj no.em...@please.post escribió: 2) this has been fixed in Py3 In my post I illustrated that the failure occurs both with Python 2.6 *and* Python 3.0. Did you have a particular version of Python 3 in mind? If the `re` module had been previously loaded (the true one, from the standard library) then this bug is not apparent. This may happen if re is imported from site.py, sitecustomize.py, any .pth file, the PYTHONSTARTUP script, perhaps other sources... The same error happens if ham\spam.py contains the single line: import smtpd, and instead of re.py there is an empty asyncore.py file; that fails on 3.1 too. En Sat, 31 Oct 2009 22:27:09 -0300, Steven D'Aprano st...@remove-this-cybersource.com.au escribió: On Sat, 31 Oct 2009 16:27:20 +, kj wrote: 1) it's a bad idea to name your own modules after modules in the stdlib Obviously, since it leads to the headaches this thread illustrates. But there is nothing intrisically wrong with it. The fact that it is problematic in Python is a design bug, plain and simple. There's no rational basis for it, Incorrect. Simplicity of implementation and API is a virtue, in and of itself. The existing module machinery is quite simple to understand, use and maintain. Uhm... module objects might be quite simple to understand, but module handling is everything but simple! (simplicity of implem...? quite simple to WHAT? ROTFLOL!!! :) ) Dealing with name clashes doesn't come for free. If you think it does, I encourage you to write a patch implementing the behaviour you would prefer. I'd say it is really a bug, and has existed for a long time. One way to avoid name clashes would be to put the entire standard library under a package; a program that wants the standard re module would write import std.re instead of import re, or something similar. Every time the std package is suggested, the main argument against it is backwards compatibility. In addition, there are use-cases where the current behaviour is the correct behaviour. Here's one way to backport (say) functools to older versions of Python (untested): You still would be able to backport or patch modules, even if the standard ones live in the std package. En Sat, 31 Oct 2009 12:12:21 -0300, kj no.em...@please.post escribió: I've tried a lot of things to appease Python on this one, including a liberal sprinkling of from __future__ import absolute_import all over the place (except, of course, in inspect.py, which I don't control), but to no avail. I think the only way is to make sure *your* modules always come *after* the standard ones in sys.path; try using this code right at the top of your main script: import sys, os.path if sys.argv[0]: script_path = os.path.dirname(os.path.abspath(sys.argv[0])) else: script_path = '' if script_path in sys.path: sys.path.remove(script_path) sys.path.append(script_path) (I'd want to put such code in sitecustomize.py, but sys.argv doesnt't exist yet at the time sitecustomize.py is executed) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: list comprehension problem
On Sat, 31 Oct 2009 14:12:40 -0400, Terry Reedy wrote: alex23 wrote: Terry Reedy tjre...@udel.edu wrote: alex23 wrote: You're completely wrong. Immutability has nothing to do with identity, ... I'm honestly not getting your point here. Let me try again, a bit differently. I claim that the second statement, and therefor the first, can be seen as wrong. I also claim that (Python) programmers need to understand why. In mathematics, we generally have immutable values whose 'identity' is their value. There is, for example, only one, immutable, empty set. I think it's more than that -- I don't think pure mathematics makes any distinction at all between identity and equality. There are no instances at all, so you can't talk about individual values. It's not that the empty set is a singleton, because the empty set isn't a concrete object- with-existence at all. It's an abstraction, and as such, questions of how many separate empty sets are there? are meaningless. There are an infinite number of empty sets that differ according to their construction: The set of all American Presidents called Boris Nogoodnik. The set of all human languages with exactly one noun and one verb. The set of all fire-breathing mammals. The set of all real numbers equal to sqrt(-1). The set of all even prime numbers other than 2. The set of all integers between 0 and 1 exclusive. The set of all integers between 1 and 2 exclusive. The set of all positive integers between 2/5 and 4/5. The set of all multiples of five between 26 and 29. The set of all non-zero circles in Euclidean geometry where the radius equals the circumference. ... I certainly wouldn't say all fire-breathing mammals are integers between 0 and 1, so those sets are different, and yet clearly they're also the same in some sense. I think this demonstrates that the question of how many different empty sets is meaningless -- it depends on what you mean by different and how many. In informatics, and in particular in Python, in order to have mutability, we have objects with value and an identity that is separate from their value. I think you have this backwards. We have value and identity because of the hardware we use -- we store values in memory locations, which gives identity. Our universe imposes the distinction between value and identity. To simulate immutability and singletons is hard, and needs to be worked at. Nevertheless, it would be possible to go the other way. Given hypothetical hardware which only supported mutable singletons, we could simulate multiple instances. It would be horribly inefficient, but it could be done. Imagine a singleton-mutable-set implementation, something like this: class set: def __init__(id): return singleton def add(id, obj): singleton.elements.append((id, obj)) def __contains__(id, element) return (id, obj) in singleton.elements and so forth. You might notice that this is not terribly different from how one might define non-singleton sets. The difference being, Python sets have identity implied by storage in distinct memory locations, while this hypothetical singleton-set has to explicitly code for identity. There can be, for example, multiple mutable empty sets. Identity is important because we must care about which empty set we add things to. 'Identity' is only needed because of 'mutability', so it is mistaken to say they have nothing to do with each other. True, but it is not a mistake to say that identity and mutability are independent: there are immutable singletons, and mutable singletons, and immutable non-singletons, and mutable non-singletons. Clearly, knowing that an object is mutable doesn't tell you whether it is a singleton or not, and knowing it is a singleton doesn't tell you whether it is immutable or not. E.g. under normal circumstances modules are singletons, but they are mutable; frozensets are immutable, but they are not singletons. Ideally, from both a conceptual and space efficiency view, an implementation would allow only one copy for each value of immutable classes. Ideally, from a complexity of implementation view, an implementation would allow an unlimited number of copies of each value of immutable classes. This is what new programmers assume when they blithely use 'is' instead of '==' (as would usually be correct in math). Nah, I think you're crediting them with far more sophistication than they actually have. I think most people in general, including many new programmers, simply don't have a good grasp of the conceptual difference between equality and identity. In plain language, is and its grammatical forms be, are, am etc. have many meanings: (1) Set membership testing: Socrates is a man. This is a hammer. (2) Existence: There is a computer language called Python. There is a monster under the bed. (3) Identity: Iron Man is Tony Stark. The butler is the murderer. (4) Mathematical
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 22:29:12 -0500, Peng Yu wrote: In my question, module A and B exist just for the sake of implementation. Even if I have module A and B, I don't want the user feel the existence of module A and B. I want them feel exact like class A and B are defined in module 'test' instead of feeling two modules A and B are in package 'test'. Inside test/__init__.py: from A import A # class A from file A.py from B import B # class B from file B.py I can not use the above approach as I mentioned its problem in my previous message. Either I have not seen it, or I have not understood it, but I don't understand why you can not use this approach. or better still: from a import A # class A from file a.py from b import B # class B from file b.py This artificially introduces the constraint that the file name can not be the same as the class/function name. There is no constraint like this if I can C++. It is not a constraint, it is a convention. You are free to ignore it if you like. Some people don't like writing glob.glob (for example). Some people would like to see Python ban modules with the same name as objects inside them, to avoid this error: import datetime ... much later from datetime import datetime datetime.datetime() Traceback (most recent call last): File stdin, line 1, in module AttributeError: type object 'datetime.datetime' has no attribute 'datetime' You seem to be inconsistent -- you say you want to name the file the same as the function in it, so you know which file to look for a function, but then you complain about writing: test.A.A so when we suggest naming A.py a.py, so you can write: test.a.A you complain about that too. Frankly, I think you are just complaining because Python isn't C++. I know that module names should be in lower cases, in general. However, it is OK to have the module name capitalized in this case since the end users don't see them. Of course they do. This sentence is confusing. Can you spell out what you mean? If you supply a package test/ +-- __init__.py +-- A.py +-- B.py there is nothing stopping your users from doing this: import test.A as A import test.B as SomethingElse [...] I have defined 'long' in one of my previous message. I consider a file long, when it does not fit in one or two screen. Basically, I want to get a whole picture of the file after glancing of the file. You must only write incredibly trivial programs then. There is more to understanding a program than understanding one single function. Any serious function will call other functions. To get the whole picture, you have to understand them too. Your requirement simply shifts the burden from open one file, and read ten functions to open ten files, and read ten functions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 22:48:10 -0500, Peng Yu wrote: Variables in a function are already private. How can the names in one function be affected by other functions in the same module? You misunderstood me. If there are multiple functions or classes in a file, when I change variables in a function/class, I have to make sure that they are not in other functions or classes. No you don't. def f(x): return x+1 def g(x): return x-1 If I choose to refactor f() and change x to y, why do I care about the internal variable inside g()? Oh wait, I get it... you want to do a global search-and-replace over the entire file. *face-palm* If your functions are less than one-screen full, why do you need a global replacement? Global replacement risks changing words in docstrings, comments etc that it shouldn't. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 22:54:47 -0500, Peng Yu wrote: So python would not be able to accommodate my preference one class/function per file? Of course it does! You can do that RIGHT NOW -- just put one class per file. I.e., I have to use something like 'from spam import spam' or 'spam.spam()', How else do you expect to use the class if you don't import it? or accept that the filename is not the same as the class/function name. So let me see... You don't want to write import spam; spam.spam() You don't want to write from spam import spam; spam() You don't want to write from Spam import spam; spam() You don't want to write from spam import Spam; Spam() What exactly do you want? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Martin v. Löwis mar...@v.loewis.de added the comment: Martin, can you please elaborate on this? I never heard of such standards in OSS. MAL already gave the link. From the link: Sometimes package developers are tempted to set user variables such as CFLAGS because it appears to make their job easier. However, the package itself should never set a user variable, particularly not to include switches that are required for proper compilation of the package. Since these variables are documented as being for the package builder, that person rightfully expects to be able to override any of these variables at build time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
New submission from Daniel Urban urban.dani...@gmail.com:
I'm trying to write an iterable class, and it behaves strangely with
itertools.zip_longest. The following example demonstrates this:
class Repeater: # this class is similar to itertools.repeat
def __init__(self, o, t):
self.o = o
self.t = int(t)
def __iter__(self): # its iterator is itself
return self
def __next__(self):
if self.t 0:
self.t -= 1
return self.o
else:
raise StopIteration
(Of course this is a trivial class, which could be substituted with
itertools.repeat, but I wanted to keep it simple for this example.)
The following code shows my problem:
r1 = Repeater(1, 3)
r2 = Repeater(2, 4)
for i, j in zip_longest(r1, r2, fillvalue=0):
... print(i, j)
...
1 2
1 2
1 2
0Traceback (most recent call last):
File stdin, line 2, in module
File zip_longest_test_case.py, line 30, in __next__
raise StopIteration
StopIteration
It seems, that zip_longest lets through the StopIteration exception,
which it shouldn't.
The strange thing is, that if I use the python implementation of
zip_longest, as it is in the documentation [1], I get the expected
result:
# zip_longest as it is in the documentation:
def zip_longest(*args, fillvalue=None):
# zip_longest('ABCD', 'xy', fillvalue='-') -- Ax By C- D-
def sentinel(counter = ([fillvalue]*(len(args)-1)).pop):
yield counter() # yields the fillvalue, or raises IndexError
fillers = repeat(fillvalue)
iters = [chain(it, sentinel(), fillers) for it in args]
try:
for tup in zip(*iters):
yield tup
except IndexError:
pass
Test code again:
r1 = Repeater(1, 3)
r2 = Repeater(2, 4)
for i, j in zip_longest(r1, r2, fillvalue=0):
... print(i, j)
...
1 2
1 2
1 2
0 2
I would think, that this is the expected behaviour.
Also, Matthew Dixon Cowles discovered, that if using list(), the C
implementation of itertools.zip_longest also works fine:
r1=Repeater(1,3)
r2=Repeater(2,5)
list(itertools.zip_longest(r1,r2,fillvalue=0))
[(1, 2), (1, 2), (1, 2), (0, 2), (0, 2)]
This is strange, and I think it really shouldn't work this way.
(Thanks for Matthew Dixon Cowles' help on the python-help mailing list.)
I'm attaching a test script, which tries all 4 variations (library
zip_longest with and without list(), and the documentation's zip_longest
impplementation with and without list()).
And another thing: it works fine in 2.6.4 (with izip_longest).
--
components: Extension Modules
files: zip_longest_test_case.py
messages: 94746
nosy: durban
severity: normal
status: open
title: itertools.zip_longest behaves strangely with an iterable class
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15238/zip_longest_test_case.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7244
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7117] Backport py3k float repr to trunk
Mark Dickinson dicki...@gmail.com added the comment: r75979: Deprecate PyOS_ascii_atof and PyOS_ascii_strtod; document PyOS_double_to_string. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I saw strange thing with following code + release26-maint/trunk. from itertools import * class Repeater(object): # this class is similar to itertools.repeat def __init__(self, o, t): self.o = o self.t = int(t) def __iter__(self): # its iterator is itself return self def next(self): if self.t 0: self.t -= 1 return self.o else: raise StopIteration r1 = Repeater(1, 3) r2 = Repeater(2, 4) for i, j in izip_longest(r1, r2, fillvalue=0): print(i, j) Be care that Repeater is using new-style class. (it's default on py3k) I couldn't see any problem with officially released windows binary, but I could see following error with VC6 debug build. (1, 2) (1, 2) (1, 2) (0, 2) XXX undetected error Traceback (most recent call last): File a.py, line 20, in module print(i, j) File a.py, line 15, in next raise StopIteration StopIteration # Still there is possibility this is VC6 bug though. -- nosy: +ocean-city ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I hope an attached patch will fix this issue. (this patch is for trunk) I think PyErr_Clear() is needed to clear StopIteration there. -- keywords: +patch versions: +Python 2.6, Python 2.7, Python 3.2 Added file: http://bugs.python.org/file15239/fix_izip_longest.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6603] Compilation error if configuref --with-computed-gotos
Mark Dickinson dicki...@gmail.com added the comment: Applied to 2.7, 2.6, 3.2, 3.1 in r75982 through r75985. -- stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6603 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
Georg Brandl ge...@python.org added the comment: The patch is incorrect; tp_iternext can raise exceptions other than StopIteration which must be let through. -- assignee: - rhettinger nosy: +georg.brandl, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7042] test_signal fails on os x 10.6
Mark Dickinson dicki...@gmail.com added the comment: I've fixed test_itimer_virtual and test_itimer_prof to use a timeout instead of an xrange/range(1) loop, in r75986 through r75989. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Mark Dickinson dicki...@gmail.com added the comment: I'm hoping (though it's only a faint hope) that the change in r75986 might allow the test suite to run to completion on the FreeBSD buildslave. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
Daniel Urban urban.dani...@gmail.com added the comment: I saw strange thing with following code + release26-maint/trunk. I tried your code (with the new-style class) with Python 2.6.4 and 2.7a0 (trunk), and both worked fine. I built them with GCC 4.2.4 on Ubuntu 8.04. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath
Jason R. Coombs jar...@jaraco.com added the comment: Based on the response, then the documentation is inadequate. I don't want to make a stink about this, but I think the issue is still unresolved. If it would be better to discuss this elsewhere, please advise. The documentation says Return a relative filepath to path either from the current directory or from an optional start point. The documentation should say Return a relative filepath to a path, where path is considered relative to the current directory, either from the current directory or from an optional start point. On Windows, a ValueError is raised if the current directory and the start path are not on the same drive. The clarification is that the path specified is _not_ relative to the start point (which would have been my guess), but is relative to another unspecified environmental condition (the current directory). To leave out this clarification means that this implicit behavior is left to the user to discover rather than to state that it's by design. For my purposes, I wanted a function that would calculate a target based on a start path and a relative or absolute path from it. Based on the documentation, I thought relpath was it. I understand better now what the purpose of relpath is, and it's not what I was expecting. I think the documentation could be improved to help manage this expectation for other users. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
Mark Dickinson dicki...@gmail.com added the comment: Patch to add %lld support to PyString_FromFormat(V). (Against the trunk.) -- keywords: +patch stage: - patch review type: - feature request Added file: http://bugs.python.org/file15240/add_lld_format.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7210] Proposed Syntax Checks in Test Suite
Chuck Rhode crh...@lacusveris.com added the comment: Thanks. -ccr- -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath
Nick Coghlan ncogh...@gmail.com added the comment: The path *returned* is relative to the start point. The target path is figured out normally (i.e. relative to the current directory if an absolute path is not given). In your example, you aren't passing in an absolute Windows path - you give a path relative to the current drive (since no drive is specified). Windows file pathing is hopeless, but it isn't the job of Python's documentation to explain its quirks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath
Jason R. Coombs jar...@jaraco.com added the comment: The documentation changes I suggested make no mention to Windows pathing quirks. They instead clarify two aspects: 1) cross-platform behavior (how the path is interpreted) and 2) platform-specific implementation of relpath (what Python exceptions to expect in exceptional conditions). These two changes would have made it clear to me from the beginning that relpath is not what I was searching for when I wanted to find a path from one path to another. I'm just trying to help those who come after me to not run into the same situation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I tried your patch on windows, your patch worked great. One little thing: I think line 346 of patch can be wrapped with #ifdef HAVE_LONG_LONG. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
Georg Brandl ge...@python.org added the comment: I tried your code (with the new-style class) with Python 2.6.4 and 2.7a0 (trunk), and both worked fine. I built them with GCC 4.2.4 on Ubuntu 8.04. The problem seems to only show up in debug builds on 2.x, but it is there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5972] Failing test_signal.py on Redhat 4.1.2-44
Mark Dickinson dicki...@gmail.com added the comment: I think this failure may now be fixed in svn: see issue #7042. dmauldin, are you in a position to test this on Red Hat with a recent svn checkout? (Either trunk or release26-maint, it doesn't matter which.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7244] itertools.zip_longest behaves strangely with an iterable class
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I've got it from here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed)
New submission from Ilya Sandler ilya.sand...@gmail.com: Currently, pressing Ctrl-C in pdb will terminate the program and throw the user into post-mortem debugging. Other debuggers (e.g gdb and pydb) treat Ctrl-C differently: Ctrl-C only stops the program and the user can resume it if needed. I believe current pdb behavior is user-unfriendly (as wanting to stop and then resume the execution is a very common use case which is not supported by pdb at all (I think)). The attached patch changes pdb's Ctrl-C behavior to match gdb's: Ctrl-C will stop the program and the user can resume the execution later. -- components: Library (Lib) files: sig.patch.v0 messages: 94764 nosy: isandler severity: normal status: open title: better Ctrl-C support in pdb (program can be resumed) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file15241/sig.patch.v0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7242] Forking in a thread raises RuntimeError
Gregory P. Smith g...@krypto.org added the comment: This only appears to happen on Solaris. What version of Solaris are you using? (i doubt that matters, i expect it happens on all versions) I haven't look closely enough at the code yet, but reinitializing the import lock in the child process should make sense here. -- assignee: - gregory.p.smith nosy: +twouters priority: - normal versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7242 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
Changes by Gregory P. Smith g...@krypto.org: -- assignee: - gregory.p.smith nosy: +gregory.p.smith -gps ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6748] test_debuglevel from test_telnetlib.py fails
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti priority: - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
Gregory P. Smith g...@krypto.org added the comment: Peter - can you apply the patch from svn r76000 and test that it works properly on Solaris? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
Antoine Pitrou pit...@free.fr added the comment: Regarding your comment in r76000: NOTE: The Python C API calls flockfile() (and unlock) during readline. This may be true in 2.x but not in 3.x. Does it have any security implication? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6748] test_debuglevel from test_telnetlib.py fails
Antoine Pitrou pit...@free.fr added the comment: This failure actually still happens quite regularly (on the buildbots and also on my Mandriva system). Judging from a quick Google search, errno 104 (ECONNRESET) should be treated as a case of EOF (it means the TCP connection was reset using RST rather than FIN, which apparently sometimes happens). Besides, the test flow in test_telnetlib really is a mess (setUp and tearDown getting called multiple times, for example), could you clean it up? -- nosy: +pitrou versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6748] test_debuglevel from test_telnetlib.py fails
Derk Drukker derk.druk...@gmail.com added the comment: This patch fixes the issue. -- keywords: +patch nosy: +drukker Added file: http://bugs.python.org/file15242/issue6748.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6748] test_debuglevel from test_telnetlib.py fails
Eric Smith e...@trueblade.com added the comment: I still get 'Connection reset by peer' on OS/X 10.5.8 with this patch (http://bugs.python.org/file15242/issue6748.patch). -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6748] test_debuglevel from test_telnetlib.py fails
Jack Diederich jackd...@gmail.com added the comment: Antoine Pitrou: Besides, the test flow in test_telnetlib really is a mess (setUp and tearDown getting called multiple times, for example), could you clean it up? Yes, I'm working on refactoring the test server and separating out testing that versus testing the telnetlib. It is the test server (which started simple and then grew cruft) which seems to have OS specific problems. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Antoine Pitrou pit...@free.fr added the comment: Looking at the frequent buildbot failures, they always seem to happen in TestMaildir. Therefore, it may have to do with the metadata-updating behaviour of the filesystem (since maildir uses one file per message). Unfortunately, while I tried to reproduce the failures on my home system with a variety of filesystems (ext3, ext4, reiserfs, xfs and even vfat), I never got any failure here. Ezio, could you give details on your system, your filesystem and its mount options? (if you don't know them, look in /proc/mounts) -- nosy: +pitrou versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
Gregory P. Smith g...@krypto.org added the comment: It might mean that other threads with access to the same file handle could interfere and intercept part of the password entry if they wanted to but thats not too concerning. py3k/Modules/_io/bufferedio.c which is presumably used when input is sys.stdin instead of a /dev/tty file appears to lock things. Compared to glibc's getpass implementation the locking should probably be done around a wider swath of getpass code in order to protect all possible race conditions of other code accessing the handle as we set it up and display the prompt. I don't really think it is something worry about as it requires code executing within the context of your own getpass calling program to be doing something that'll interfere with your password reading. If someone has -that- problem they have bigger issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6748] test_debuglevel from test_telnetlib.py fails
Derk Drukker derk.druk...@gmail.com added the comment: The change in the patch worked for me on py3k on Ubuntu 9.10. It makes sense, though, that it could still fail: conn can get closed too soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Garrett Cooper yaneg...@gmail.com added the comment: I'm trying to resolve this issue on: 2.6-releasemaint trunk 3.1-releasemaint py3k first by resolving issues configure.in, but there are a TON of AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is (25 on 2.x -- 27 on 3.x). Is requiring the end-user to define the autoconf variables appropriately to their platform when running configure (when provided an error message telling them so), a longterm sustainable requirement? I know it isn't as user friendly, but this is a definite problem that either needs to be fixed in the autoconf tests (if possible) or the C code itself. I wouldn't mind updating the INSTALL or README files to reflect this change either, if needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Gregory P. Smith g...@krypto.org added the comment: Documenting the parameters needed to avoid all AC_TRY_RUNs is a good first step for any that are not obvious how to convert from AC_TRY_RUN into something else. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Antoine Pitrou pit...@free.fr added the comment: Ezio, could you give a try to the following patch? -- keywords: +patch Added file: http://bugs.python.org/file15243/test_mailbox.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Antoine Pitrou pit...@free.fr added the comment: Another possible explanation is that the logic for computing Maildir._last_time is wrong. It should be computed before refreshing the internal cache, not after. Here is a patch. -- Added file: http://bugs.python.org/file15244/test_mailbox2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Antoine Pitrou pit...@free.fr added the comment: According to testers, both patches fail at addressing the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file15243/test_mailbox.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file15244/test_mailbox2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath
Nick Coghlan ncogh...@gmail.com added the comment: os.relpath *does* give you a relative path between two directories. The problem you are encountering is that, on Windows, a relative path doesn't even *exist* if the two directories are on different drives (which is exactly what the error message says). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6896] Intermittent failures in test_mailbox
R. David Murray rdmur...@bitdance.com added the comment: I hacked mailbox.py so that a _toc refresh is always done and ran the tests in a loop, and did not get a failure in 30+ runs, whereas without that hack I would get failures almost every run. So I think Antoine is on the right track. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7245] better Ctrl-C support in pdb (program can be resumed)
Raghuram Devarakonda draghu...@gmail.com added the comment: It is better for this functionality to be added in Cmd module as that will benefit all users of that module. Please see bug #1294 which has a patch for this purpose. It would be nice if you can test with that patch and see if pdb works as you expected. -- nosy: +draghuram ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
