New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
It would be useful to compare the contents of two files while not caring what
platform they were produced on, perhaps a universal_line_endings parameter to
e.g. filecmp.cmp and possibly other methods.
At the moment opening
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2118
___
___
Python-bugs
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1820
___
___
Python-bugs
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
Consider the following code:
### keywords.py
def f(**kw):
print arg, kw
f(hello, keyword=True)
and compare the behaviour in Python 2.6 and Python 2.7:
$ python keywords.py
Traceback (most recent call last):
File
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I think the unhelpful part is mostly that it does not distinguish between
argument types any more when the distinction is important in this context. In
fact, it could be argued that what it said isn't even true:
f() takes exactly
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I also just ran into this. Is it likely that an enhancement request to provide
access to the raw command line, as requested by the previous commenter, would
be accepted? It's sometimes useful to have some idea about what kind
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Interesting. Any idea if something similar is possible on Linux?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2972
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I agree with Nick :)
Though I'd say fixing a regression should take priority over further enhancing
the messages.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Thanks for the tips, looks like we have the basis for a solid workaround here.
Perhaps that could be encapsulated and added as sys.raw_argv or something in
future?
--
___
Python
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
I have the following setup.py script:
#!/usr/bin/env python
from distutils.core import setup
scripts=[hello.py]
setup(scripts=scripts)
I have two different python installations (using virtualenv) where I
wish to install
New submission from Geoffrey Bache [EMAIL PROTECTED]:
If a python script receives SIGINT while the interpreter is starting up,
it's possible to get the message import site failed; use -v for
traceback printed on standard error and for execution to proceed. It
also seems to be possible to get
New submission from Geoffrey Bache [EMAIL PROTECTED]:
Run the following code on Windows:
import subprocess, os
file = open(filename, w)
try:
proc = subprocess.Popen(nosuchprogram, stdout=file)
except OSError:
file.close()
os.remove(filename)
This produces the following exception
Geoffrey Bache [EMAIL PROTECTED] added the comment:
A note on workarounds, the garbage collector seems to release the
handles when the function exits, so removing the file in a caller works
for me. However Tim's proposed fix with os.close didn't do so
Geoffrey Bache [EMAIL PROTECTED] added the comment:
Well, strictly speaking, yes. It just feels like a rather major omission
(when Python can do xmlrpc and handle proxies you hope it will handle
the combination).
Desperate doesn't really have a timeline, strangely enough :) I know I
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2986
___
___
Python-bugs
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4057
___
___
Python-bugs
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I can see your point, though I think particularly in this case it's
(unfortunately) fairly common that scripts on POSIX platforms read $PWD
instead of finding the current working directory properly.
I'm probably not the first
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
You misunderstand: I am not reading $PWD. I need to call a C program as
a subprocess, which is written by a third party and which determines its
current working directory by reading $PWD. os.chdir will not have any
effect
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I tried that and it didn't work, though not for this reason. I'm also
trying to read the output from the subprocess via a pipe and that wasn't
being collected for some reason. I didn't really track down why so far,
if it makes
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
The default buffering of standard output and standard error has changed in
Python 3.x with respect to Python 2.x, and I have been unable to find decent
documentation of either the current behaviour, or the change.
(See also
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I would certainly be in favour of restoring the python 2.x behaviour, at least
where standard error is concerned. When writing Python programs, it's important
to see exceptions immediately, and not lose them entirely in some
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Ooops, seems like I just ran into a bug in the bug tracker too, it seems to
have backed out other people's changes. Restoring them...
--
components: +IO
nosy: +benjamin.peterson, pitrou, pjenvey, stutzbach
versions
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13601
___
___
Python-bugs
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I'm hesitant to make it line-buffered by default when directed to a
file, since this could significantly slow down a program that for some
reason produces super-voluminous output (e.g. when running a program
with heavy debug
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
The changes are good as far as they go, but they only affect the documentation
of sys.stderr and sys.stdout.
I also suggested changes to the documentation of the -u flag, and to What's
New in Python 3.0, can someone look
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
I think we all agree line-buffering is sufficient, so I change the title.
--
title: sys.stderr should be unbuffered (or always line-buffered) - sys.stderr
should always be line-buffered
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Thanks.
I'm not sure what you've written about the -u flag is correct though
currently. From experimenting I believe it changes buffering of stdout and
stderr to line-buffering also when directed to file, i.e. it does affect
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
The locale module provides locale.getdefaultlocale and
locale.getpreferredencoding. The encodings returned by each are generally
subtly different ('ISO8859-1' vs 'ISO-8859-1'), but the difference between
these methods
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
Reading through the datetime module documentation, various places that refer to
datetime.time objects are in fact links to the time module. They should
refer to the appropriate section on the same page.
--
messages
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13076
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
Here I'm referring to the section about RequestHandler objects under the
SocketServer page.
http://docs.python.org/release/2.7.2/library/socketserver.html#requesthandler-objects
This appears to be the same in Python 2.6
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Thanks, didn't know about that feature.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1748960
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Just ran into this myself, and would agree with Christian's comments. On
my system, my home directory is a mounted network drive, hence H:\. It
was a bit of a surprise when os.path.expanduser(~fred) returned
H:\\fred...
This seems
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
In fact, wouldn't a very simple fix be to not return paths that don't
exist? That would probably catch 90% of the cases.
--
___
Python tracker rep...@bugs.python.org
http
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
Recently tried to use the logging configuration file format as
understood by logging.config.fileConfig() and found it very unwieldy for
normal usage. I feel it needs to scale down better. Some thoughts:
a) It creates handlers
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
a) What is the point of opening files that will never be written to and
sockets that will never be used?
A large application might have a great many loggers for debugging which
are off by default, and this means you have to either
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
OK, I'll take point (c) further on comp.lang.python. As for the others,
it would be useful if you could at least understand my points.
a) I'm aware that there isn't necessarily a one-to-one correspondence
between loggers and files
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
OK, I hadn't seen the delay parameter until now. I guess this is new
in Python 2.6? Good that there is already a way to avoid lots of empty
files, though it'll be a while before I can assume Python 2.6
unfortunately... that probably
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
Who said anything about not supporting users who want the hierarchy? I'm
talking about making qualname optional, not removing it
entirely! I even supplied the entirety of the code (all 4 lines of it)
to be clear what I meant
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
If it was never intended for end users, then perhaps you could rename
this request as provide an end-user-friendly log configuration format
(that would live alongside the current one). It's hardly unusual that
users should be able
Geoffrey Bache gjb1...@users.sourceforge.net added the comment:
My comp.lang.python thread is here:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/a0c35c3c9ad210a4
It was met by deafening silence though.
I don't see why a simple format would need to be customer-specific
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12739
___
___
Python-bugs
Geoffrey Bache added the comment:
Just ran into this on Python 2.6 also.
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12739
Geoffrey Bache added the comment:
Thanks Victor, yes I already created my own lock which fixed the issue for me.
Maybe it would be worth adding a note to the documentation about this in the
meantime (especially for Python 2)?
--
___
Python tracker
Changes by Geoffrey Bache gjb1...@users.sourceforge.net:
--
nosy: +gjb1002
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15451
___
___
Python-bugs
Geoffrey Bache added the comment:
@Valentyn Tymofieiev - true, and thanks for the tip, though the symptoms
described there are somewhat different from what I'm observing. Also, my
problem seems to be dependent on zipping the Python code, which that one isn't
Geoffrey Bache added the comment:
I have been experiencing what I thought was this issue in my embedded Python
code. We have been using Python 3.7, so I thought upgrading to 3.8.1 would fix
it, but it doesn't seem to have made any difference.
My C++ code essentially can call
Geoffrey Bache added the comment:
Oops, I mean we call PyImport_ImportModule and get these issues when the files
are zipped. Unless that calls PyImport_GetModule internally I guess it's not
related to this then.
--
___
Python tracker
<ht
Change by Geoffrey Bache :
--
nosy: +gjb1002
___
Python tracker
<https://bugs.python.org/issue38884>
___
___
Python-bugs-list mailing list
Unsubscribe:
49 matches
Mail list logo
