[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: R. David Murray wrote: > There are two questions here: (1) is this behavior consistent across all > microsoft platforms we support? I'll be honest: I don't know. > (2) is this *change* in behavior of Popen acceptable? I don't know that either. > I'll be mo

[issue8404] Set operations don't work for dictionary views

Alexandre Vassalotti added the comment: Committed in r80749 and r80751 (for py3k). Thank you! -- resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue3620] test_smtplib is flaky

R. David Murray added the comment: If it would provide clearer error message in cases of failure, it sounds like a reasonable thing to add whether or not the failure in this issue is still happening. -- nosy: +r.david.murray ___ Python tracker

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: Well, it wouldn't be the first time the microsoft docs were wrong. There are two questions here: (1) is this behavior consistent across all microsoft platforms we support? (2) is this *change* in behavior of Popen acceptable? For (1) we need a unit test ad

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: I'm probably as ignorant as you are of Windows issues. I just know what my experiments tell me: if you force the contents of any explicit 'env' argument into os.environ before calling Popen, you get the same behavior as on *nix. -- ___

[issue8607] OSX: duplicate -arch flags in CFLAGS breaks sysconfig

R. David Murray added the comment: This is a duplicate of issue 8366. -- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> OS X universal builds fail on 2.7b1 and py3k with "Don't know machine value for archs"

[issue1054967] bdist_deb - Debian packager

Andrew Straw added the comment: I have moved the recent discussion on stdeb to a thread on the distutils-sig. -- ___ Python tracker ___ ___

[issue8607] OSX: duplicate -arch flags in CFLAGS breaks sysconfig

New submission from Robin Dunn : In Python 2.7b1, building on OSX 10.6 with this configure command: export CC=gcc-4.0 export CXX=g++-4.0 export MACOSX_DEPLOYMENT_TARGET=10.4 ../configure \ --with-universal-archs=32-bit \ --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk \

[issue8557] subprocess PATH semantics and portability

R. David Murray added the comment: Sorry for my Windows ignorance, but if CreateProcess ignores the PATH, how does updating the PATH fix the problem? -- ___ Python tracker ___ _

[issue3620] test_smtplib is flaky

Giampaolo Rodola' added the comment: Adding this: def handle_error(self): raise ...to SimSMTPChannel class would help to provide a clearer error message to understand where exactly EBADF comes from, altough I think this was an old asyncore bug which have already been fixed. Is th

[issue8557] subprocess PATH semantics and portability

Dave Abrahams added the comment: Not to appear impatient, but It's a fairly tidy answer, I think :-) -- ___ Python tracker ___ ___

[issue8557] subprocess PATH semantics and portability

Changes by Dave Abrahams : Removed file: http://bugs.python.org/file17142/probe.py ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > I think that a developer will only switch to os.getenvb() if he/she > has troubles with the encodings. That's indeed a positive feature of this proposed change. -- ___ Python tracker

[issue8603] Create a bytes version of os.environ and getenvb()

STINNER Victor added the comment: > I also worry that people won't get it right any better than Python (...) Developers coming from Python2 will continue to use os.getenv() and will not worry about encoding, and maybe not notice that the result is now unicode (and not more a byte string). I

[issue7946] Convoy effect with I/O bound threads and New GIL

Nir Aides added the comment: I updated bfs.patch with improvements on Windows XP. The update disables priority boosts associated with the scheduler condition on Windows for CPU bound threads. Here is a link to ccbench results: http://bugs.python.org/file17194/nir-ccbench-xp32.log Summary:

[issue8603] Create a bytes version of os.environ and getenvb()

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> Here's one (RFC 3875, sections 4.1.7 and 4.1.5): >> >> LANG = 'en_US.utf8' >> CONTENT_TYPE = 'application/x-www-form-urlencoded' >> QUERY_STRING = 'type=example&name=Löwis' >> PATH_INFO =

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > Using os.getenvb(), you can decode the string using the right > encoding (which may be different for each variable). Ok. If that's the motivation, the documentation should make that clear (there isn't any documentation in the patch, anyway). I'm worried that

[issue7946] Convoy effect with I/O bound threads and New GIL

Changes by Nir Aides : Removed file: http://bugs.python.org/file16967/bfs.patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue7946] Convoy effect with I/O bound threads and New GIL

Changes by Nir Aides : Added file: http://bugs.python.org/file17194/nir-ccbench-xp32.log ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue8514] Create fsencode() and fsdecode() functions in os.path

STINNER Victor added the comment: > IIUC, that usage is an equivalent transformation, i.e. the code doesn't > change its behavior. It is mere refactorization. I changed os.getenv() to accept byte string key (in a previous commit), but I don't like this hack. If we have os.environb, os.getenv()

[issue8603] Create a bytes version of os.environ and getenvb()

STINNER Victor added the comment: > Can somebody please explain what problem is being solved with this patch? The problem is that we don't have reliable algorithm to get the encoding of each environment variable. We cannot ensure that all variables are encoded "correctly". Using os.getenvb()

[issue8604] Adding an atomic FS write API

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > Your name will end up being partially escaped as surrogate: > > 'L\udcf6wis' > > Further processing will fail That depends on the further processing, no? > Traceback (most recent call last): > File "", line 1, in > UnicodeEncodeError: 'latin-1' codec c

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Antoine Pitrou : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/op

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: Roundup ate my code. I meant: >>> s = socket.create_connection(("python.org", 80), >>> source_address=("192.168.0.2", 0)) >>> s.getsockname() ('192.168.0.2', 40496) -- ___ Python tracker

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: > You mean that socket.create_connection(), httplib (issue 3972) and > ftplib (issue 8594) should have used a different API to implement > their "source_address" option? source_address=("192.168.0.2", 0)) >>> s.getsockname() ('192.168.0.2', 40

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Giampaolo Rodola' added the comment: > Any time you have any API that you want to test that requires a > pre-allocated port number, you're going to have intermittent failures. > Such APIs are broken and should be fixed where possible and avoided > otherwise. You mean that socket.create_conn

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Giampaolo Rodola' : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Giampaolo Rodola' added the comment: > Any time you have any API that you want to test that requires a > pre-allocated port number, you're going to have intermittent failures. > Such APIs are broken and should be fixed where possible and avoided > otherwise. You mean that socket.create_conn

[issue8603] Create a bytes version of os.environ and getenvb()

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> Set your CODESET to ASCII and watch the surrogate escaping >> begin... seriously, Martin, if you've ever worked with CGI >> or WSGI or FastCGI or SCGI or any of the many other protocols >>

[issue8606] OSF is not supported anymore

Jesús Cea Avión added the comment: I am unsupporting OSF* systems. If that is too much to deprecate, change it to deprecate only OSF1. Commit at r80728. -- resolution: -> accepted status: open -> closed type: -> feature request ___ Python tracker

[issue8586] test_imp.py test failures on Py3K Mac OS X

Michael Foord added the comment: Yep, same here. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > Here's one (RFC 3875, sections 4.1.7 and 4.1.5): > > LANG = 'en_US.utf8' > CONTENT_TYPE = 'application/x-www-form-urlencoded' > QUERY_STRING = 'type=example&name=Löwis' > PATH_INFO = '/home/löwis/bin/mycgi.py' > > (HTML uses Latin-1 as default encoding and

[issue8586] test_imp.py test failures on Py3K Mac OS X

Barry A. Warsaw added the comment: How odd. I'm on r80727 in py3k. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > Set your CODESET to ASCII and watch the surrogate escaping > begin... seriously, Martin, if you've ever worked with CGI > or WSGI or FastCGI or SCGI or any of the many other protocols > that use the OS environment for passing data between processes, > it does

[issue8603] Create a bytes version of os.environ and getenvb()

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> Please see the discussion on http://bugs.python.org/issue8514 >> for details. > > I can't see any report of actual breakage in that report, only claims of > potential breakage (with no su

[issue8586] test_imp.py test failures on Py3K Mac OS X

Michael Foord added the comment: Hmm... happens reliably for me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue8586] test_imp.py test failures on Py3K Mac OS X

Barry A. Warsaw added the comment: I cannot reproduce this on my 10.6.3 machine either running the full test suite, or running: ./python.exe Lib/test/test_imp.py ./python.exe -m unittest test.test_imp -- resolution: -> works for me ___ Python trac

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > An issue was opened 2 years ago: "It was brought up in a discussion > of sending non-ASCii data to a CGI-WSGI script where the data would > be transferred via os.environ." => #4006 (closed as "wont fix"). Fortunately, that issue could now be reconsidered as

[issue8603] Create a bytes version of os.environ and getenvb()

STINNER Victor added the comment: An issue was opened 2 years ago: "It was brought up in a discussion of sending non-ASCii data to a CGI-WSGI script where the data would be transferred via os.environ." => #4006 (closed as "wont fix"). -- ___ Python

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: > Please see the discussion on http://bugs.python.org/issue8514 > for details. I can't see any report of actual breakage in that report, only claims of potential breakage (with no supporting examples) -- ___ Python

[issue8603] Create a bytes version of os.environ and getenvb()

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > Can somebody please explain what problem is being solved with this patch? The way os.environ is currently set up on Unix breaks applications using the environment to pass data to helper ap

[issue8606] OSF is not supported anymore

Changes by Martin v. Löwis : -- nosy: +loewis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8514] Create fsencode() and fsdecode() functions in os.path

Martin v. Löwis added the comment: STINNER Victor wrote: > STINNER Victor added the comment: > >> Why is that? In msg104063, you claim that you want to create these >> functions to deal with file names (not environment variables) > > Yes, but my os_path_fs_encode_decode-3.patch uses it in get

[issue8606] OSF is not supported anymore

New submission from Jesús Cea Avión : OSF* platform seems to be pretty dead. We are moving it to unsupported state, as documented in PEP11. The first phase is Python 3.2: Configure will fail win OSF* platforms. This configuration failure will be trvivially reversible. If nobody stands up to t

[issue8514] Create fsencode() and fsdecode() functions in os.path

STINNER Victor added the comment: > Why is that? In msg104063, you claim that you want to create these > functions to deal with file names (not environment variables) Yes, but my os_path_fs_encode_decode-3.patch uses it in getenv() which is maybe a bad idea: os.environb may avoid this. > in m

[issue8390] tarfile: use surrogates for undecode fields

STINNER Victor added the comment: My patch changes test_uname_unicode() of test_tarfile for the GNU and ustar formats (but not PAX). In GNU and ustar formats, the fields can be encoded in any encoding, and may contain invalid byte sequences. -- ___

[issue8390] tarfile: use surrogates for undecode fields

Martin v. Löwis added the comment: I think it is helpful to read the pax specification here: http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html pax defines (IIUC) that all strings in a pax-compliant tar file are UTF-8 encoded. For the "invalid" option, they offer the alternative

[issue8603] Create a bytes version of os.environ and getenvb()

Martin v. Löwis added the comment: Can somebody please explain what problem is being solved with this patch? -- ___ Python tracker ___ ___

[issue8390] tarfile: use surrogates for undecode fields

STINNER Victor added the comment: A better fix is maybe to store fields as bytes, but it would break the compatibility and unicode is pratical in Python3. -- ___ Python tracker

[issue8514] Create fsencode() and fsdecode() functions in os.path

Martin v. Löwis added the comment: > I think that we cannot decide correctly about fs*code() until we decided for > os.environb. Why is that? In msg104063, you claim that you want to create these functions to deal with file names (not environment variables), in msg104064, you claim that #8513

[issue8605] gdb API issues

STINNER Victor added the comment: See #8482 for the "Unable to read information on python frame" issue. -- nosy: +haypo ___ Python tracker ___ ___

[issue8600] test_gdb failures

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue8390] tarfile: use surrogates for undecode fields

Lars Gustäbel added the comment: Yes, I will soon have ;-) Please give me a few days... -- ___ Python tracker ___ ___ Python-bugs-list

[issue8604] Adding an atomic FS write API

Changes by Tarek Ziadé : -- title: Alias for distutils.file_util.write_file in e.g. shutils -> Adding an atomic FS write API ___ Python tracker ___ __

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Tarek Ziadé added the comment: @Antoine, @Eric: After some more thoughts a contextlib makes more sense. I also have a use case for an atomic copytree() but I guess that can be an option in copytree() -- ___ Python tracker

[issue8535] passing optimization flags to the linker required for builds with gcc -flto

Marc-Andre Lemburg added the comment: Matthias Klose wrote: > > Matthias Klose added the comment: > > my understanding is that the builder is allowed to overwrite OPT, but not > BASECFLAGS. The builder should actually be allowed to override the complete CFLAGS and LDFLAGS settings, but for

[issue3720] segfault in for loop with evil iterator

Terry J. Reedy added the comment: The fix works for 3.1.2, giving TypeError: iter() returned non-iterator of type 'BadIterator' Too late to patch 2.5. Is there any intention of patching 2.6 before its final bug-fix release, in a couple of months? -- keywords: -needs review, patch ver

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

Changes by Alexander Belopolsky : -- keywords: +needs review stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailin

[issue665761] reduce() masks exception

Changes by Alexander Belopolsky : -- keywords: +needs review stage: unit test needed -> patch review ___ Python tracker ___ ___ Pytho

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Antoine Pitrou added the comment: > Giving the ability to the developers to work in a context manager > means that you potentially give them the ability to break this > atomicity. AFAICT this doesn't make sense. The writing isn't atomic, the renaming is. -- ___

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Eric Smith added the comment: I agree that with the addition of the new requirement that it be an atomic write, it should be in a library. I'd also do it as a context manager, since that's the more general case. distutils2 can either call the context manager version, or have a trivial functi

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

Bruce Frederiksen added the comment: I have also hit this error. I went to report it but found it already entered (good news), but not resolved from nearly a year ago (bad news). The error masked another bug that I had in my program and it took me quite awhile to figure out what the real pro

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Jean-Paul Calderone added the comment: Considering that it's extremely difficult to implement this correctly and in a cross-platform way, I think it makes sense as a stdlib addition (though I'd add it as a method of a `path` type rather than to the "shell utilities" module ;). -- nosy

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Tarek Ziadé added the comment: This idiom makes sense when you want to do some things with an open file, and replaces the usual try..finally idiom. That's not what we want to do here. We want to write data in a file in a single step, in an atomic manner. Giving the ability to the developers

[issue8601] bz2.BZ2File should support "with" protocol per PEP 343

Matt Wartell added the comment: Sorry for the dup, and thanks for the patch. My patch for Module/bz2module.c was almost done - I learned a lot in the process, but foremost to check better for dups, first ;) -- ___ Python tracker

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Antoine Pitrou added the comment: > Well, a context manager sounds overkill since we just want to write > some content in a file (and nothing else during that context). Using a context manager, though, is the recommended idiom to write files. I think there's a value in remaining consistent. We

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Tarek Ziadé added the comment: Notice that "contents" could be replaced here by an iterator, that would return data to send to write() -- ___ Python tracker ___

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Tarek Ziadé added the comment: Well, a context manager sounds overkill since we just want to write some content in a file (and nothing else during that context). I think a simple call is straightforward: shutil.atomic_write("foo", "contents", mode="wb") -- ___

[issue7865] io close() swallowing exceptions

Antoine Pitrou added the comment: Thanks for the patch! It was committed in r80720 (trunk), r80721 (2.6), r80722 (py3k), r80723 (3.1). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue8586] test_imp.py test failures on Py3K Mac OS X

Tim Golden added the comment: Sorry, typing too fast: http://bugs.python.org/issue7443 - test.support.unlink issue on Windows platform at least insofar as the issue applies to Windows. I imagine that the OS X thingis completely different. -- __

[issue8605] gdb API issues

New submission from Antoine Pitrou : I now get the following failures in test_gdb: == FAIL: test_pyup_command (test.test_gdb.StackNavigationTests) Verify that the "py-up" command works ---

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue8600] test_gdb failures

Antoine Pitrou added the comment: The patch wasn't exactly good. Here is a working patch. Applying it reveals a couple of different failures, but I will open a separate issue. -- Added file: http://bugs.python.org/file17193/ignore-stderr-thread-noise2.txt _

[issue8593] Improve c-api/arg.rst

Antoine Pitrou added the comment: I've applied Eric's and Brian's suggestions and committed the patch to r80714 (py3k) and r80715 (3.1). Thank you! -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue8600] test_gdb failures

Dave Malcolm added the comment: Is the message about threads emitted every time you run python under gdb? Does gdb work? If so we should simply filter out the error message. I'm attaching a patch which strips out that error message from stderr (assuming that I reformatted it for line-lengths

[issue8581] Logging handlers do not handle double-closing very well

Vinay Sajip added the comment: Fix checked into release26-maint (r80713). -- resolution: out of date -> fixed status: open -> closed ___ Python tracker ___ __

[issue1682942] ConfigParser support for alt delimiters

Tres Seaver added the comment: I'm afraid the patch no longer applies cleanly to the trunk, although at least updating the docs should be easier now that they are converted to ReStructuredText. The tests in the patch for the new feature seem sensible. -- nosy: +tseaver ___

[issue5565] Strange behavior when I logout() with IMAP4_SSL

R. David Murray added the comment: FWIW on my cisco firewalls the logs contain a lot of 'deny, no connection' messages for RST packets, probably coming from similar scenarios. -- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed ___

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Vinay Sajip added the comment: I've applied the logging patch and checked into trunk (r80712). -- ___ Python tracker ___ ___ Python-bu

[issue8601] bz2.BZ2File should support "with" protocol per PEP 343

R. David Murray added the comment: Indeed, and it was considered a feature request and thus is not appropriate for backport. If you wish to see that decision changed I think you will need to appeal to python-dev. -- nosy: +r.david.murray resolution: -> out of date stage: needs patch

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Jean-Paul Calderone added the comment: > I'm not sure if I agree that find_unused_port() should be removed though; it > does serve a purpose in very rare corner cases. It can serve a purpose in any number of cases. My point is that it's *always* unreliable, though. Any time you have any API

[issue839159] iterators broken for weak dicts

Tres Seaver added the comment: I can confirm that the patch applies with minimal fuzz to the release26-maint branches and the trunk, and that the added tests fail without the updated implementation in both cases. Furthermore, Jim's original demo script emits it error with my stock 2.6.5 Python,

[issue8601] bz2.BZ2File should support "with" protocol per PEP 343

Tres Seaver added the comment: BZ2File objects already support the context manager protocol on the trunk, as of Antoine Pitrou's fix for http://bugs.python.org/issue3860 -- nosy: +tseaver ___ Python tracker __

[issue8586] test_imp.py test failures on Py3K Mac OS X

Barry A. Warsaw added the comment: Surely not bug 7743 "Additional potential string -> float conversion issues." -- ___ Python tracker ___ ___

[issue8603] Create a bytes version of os.environ and getenvb()

STINNER Victor added the comment: > The patch is also missing code which keeps the two dictionaries in > sync. If os.environ changes, os.environb would have to change as > well. No, it doesn't :-) os.environ and os.environb are synchronized and there is a test for this! ;-) I will see later f

[issue8603] Create a bytes version of os.environ and getenvb()

Marc-Andre Lemburg added the comment: A view comments on the patch: +def __init__(self, data, encodekey, decodekey, encodevalue, decodevalue, putenv, unsetenv): As general guideline: When adding new parameter, please add them to the end of the parameter list and preferably with a default

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Antoine Pitrou added the comment: > @Antoine: Yes, that would be the idea (provide a robust pattern by > using a temporary file, then rename it) Then perhaps it would be better as a context manager: with shutil.atomic_write("foo", "wb") as f: f.write("mycontents") --

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Tarek Ziadé added the comment: @Eric: remember that distutils is frozen, so it won't be removed. And historically Distutils code was meant to be 2.4 compatible (thus, no with) @Antoine: Yes, that would be the idea (provide a robust pattern by using a temporary file, then rename it) -

[issue8601] bz2.BZ2File should support "with" protocol per PEP 343

Changes by Brian Curtin : -- stage: -> needs patch versions: +Python 3.2 -Python 2.6 ___ Python tracker ___ ___ Python-bugs-list maili

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Eric Smith added the comment: Does the standard library really need something so trivial? I'd put it in your own program. And I'd make the one in distutils private (and fix it to use a with statement). -- nosy: +eric.smith ___ Python tracker

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

Antoine Pitrou added the comment: This sounds silly to me. You can write a file in two lines: with open("foo", "wb") as f: f.write(contents) If you want to do something more useful, you can add a function for atomic writing of a file. -- nosy: +pitrou versions: +Python 3.2 -Pytho

[issue8604] Alias for distutils.file_util.write_file in e.g. shutils

New submission from Olemis Lang : Often I have the contents to be written in a file at a given path that I know as well. I recently tried to find a function in stdlib to do that and to my surprise this is what I found : - Such function exists - It's `distutils.file_util.write_file` IMO the la

[issue3445] Ignore missing attributes in functools.update_wrapper

July Tikhonov added the comment: To Evan Klitzke (eklitzke): >I'm also interested in seeing this fixed. In the current behavior, >the following code doesn't work: > ><<< start code >from functools import wraps > >def magic(func): > @wraps(func) > def even_more_magic(*args): >

[issue8586] test_imp.py test failures on Py3K Mac OS X

Tim Golden added the comment: This is basically issue 7743 which is a combination of: * Using the same filename for all tests in one process * Something (TSvn / Virus Checker) having a delete-share handle * Not renaming the file before removing it in test.support.unlink MvL suggested a change

[issue8586] test.support errors (py3k)

Changes by Michael Foord : -- title: test_imp.py test failures on Py3K Mac OS X -> test.support errors (py3k) ___ Python tracker ___ __

[issue8586] test_imp.py test failures on Py3K Mac OS X

Michael Foord added the comment: I'm seeing a "similar" (but not identical) failure on py3k / Windows 7 in test_marshal. Failure in the same code path in support.py: == ERROR: test_floats (__main__.FloatTestCase) -

[issue8596] crypt blowfish 'ignores' salt

Mark Dickinson added the comment: Okay, thanks for the update! Looks like the FreeBSD crypt manpage could use some work... -- ___ Python tracker ___

[issue8596] crypt blowfish 'ignores' salt

pvo added the comment: OpenBSD's crypt(3) mentions some bcrypt*() functions. One of this functions is "char * bcrypt_gensalt(u_int8_t log_rounds)". It produces salts like: $2a$04$7.zkQ.HPURlplcFTWgDL3u or $2a$04$l2SuIEWPqF4D3uMTABgBYO Passing this salts to Pyton's crypt.crypt on FreeBSD works

[issue8603] Create a bytes version of os.environ and getenvb()

STINNER Victor added the comment: The patch creates also fsencode()/fsdecode() functions proposed in #8514: I can rename them to use protected name (eg. "_encodeenv" and "_decodeenv") until we decided for these functions. -- ___ Python tracker

  1   2   >