Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I can't reproduce the problem. It works fine for me, displaying the box
drawing character. In case it matters, sys.getpreferredencoding returns
'ANSI_X3.4-1968'; this is on Linux, idle started
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Did you chose "for all users", or "just for me"?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
&
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
(there is currently no patch attached)
I don't think getcwd() should be fixed as getcwdb(). It's not possible
to tell what the intention of the call was, in which case I recommend
not to change the code at all.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> May be call of SetDllDirectory with argument path to python executable
> before to load a python module may help.
I'm skeptical. According to the documentation, "The directory from which
the application loaded.&quo
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Which charset is used when you use bytes filename?
It's the "ANSI" code page, which is a system-wide admin-modifiable
indirection to some real code page (changing it requires a reboot).
In the API, it's ref
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for pointing that out. I rebuilt the icons file on my build
machine, so future releases should pick up the new icons.
--
nosy: +loewis
resolution: -> fixed
status: open
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
See the "Vista Note" on
http://www.python.org/download/releases/2.6/
Closing as "won't fix".
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I've committed sys.setfilesystemencoding as r66769.
Declaring it as a documentation issue now. Not sure whether it should
remain a release blocker; IMO, the documentation can still be produced
after the release.
--
assig
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> @loewis: I guess that your locale is still UTF-8.
To refute this claim, I reported that locale.getpreferredencoding
reports 'ANSI_X3.4-1968'. I was following your instructions exactly
(on Debian 4.0), and still, it
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is incorrect. On Windows, if the path contains characters with no
representation in CP_ACP, encoding the path as bytes makes it invalid.
--
nosy: +loewis
___
Python tracker <[EMAIL
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think this should be deferred to 3.1. I'm not sure how much
consistency across platforms is desirable, however, using strings is
surely the better choice on Windows. I could sympathize with providing
bytes support only on POS
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Looks fine to me, please apply.
--
keywords: -needs review
nosy: +loewis
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Certainly not for 2.5 or 2.6. Targetting this as 2.7.
--
nosy: +loewis
versions: +Python 2.7 -Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4042>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Amaury, when I tried to run IDLE from the command line as you suggested
> I got:
>
> C:\>C:\python26\Lib\idlelib\idle.py
This is not what Amaury suggested. He suggested that you put the path
to python.exe befor
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Closing as "works for me", then.
--
resolution: -> works for me
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
What operating system are you using?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is a patch that fixes the problem as proposed. An installer built
with that patch is available from
http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-3.0.14158.msi
--
keywords: +patch
Added file: http://bugs.pyth
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
So what's the status of this? Who is still interested in seeing what
patches considered?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is a patch that should fix this.
--
keywords: +needs review, patch
priority: critical -> release blocker
Added file: http://bugs.python.org/file11712/init.diff
___
Python tracke
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
keywords: +needs review
priority: normal -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, I have now removed the Alpha designation, in r66814, r66815, and r66816.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Please create a separate tracker item per individual change (or per
group by enourmously similar changes). Each change will be reviewed
separately, and will get accepted or rejected separately.
This specific patch (Python-unicode-re
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This has been fixed in r66739.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Would it possible to close this issue since os.listdir() is fixed and
> many other related functions (posix, posixpath, ntpath, macpath, etc.)
> are also fixed?
IIUC, these fixes are still not complete: they lack docume
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Most (or all) patches include new tests about bytes. Here is a patch for
> os.rst documentation about listdir(), getcwdb() and readlink().
Thanks! Committed as r66829.
I've added additional documentation in r66830, whic
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3187>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
What's the purpose of the additional YY substring?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I agree with Trent that this is a bug, and I agree with the second patch
(pymacconfig.h.patch2).
Mark-Andre, sys.byteorder is not affected because detects the byte order
at run-time, not at compile-time. Likewise, in the struct
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you come up with a test case?
Also, it would probably be good to document what parameters can have
what datatypes in the exec family of functions.
___
Python tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks! Committed as r66831
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> When using a universal build of python on macosx
> distutils.util.get_platform should use "fat" for the machine
> architecture, instead of the architecture of the current machine.
Can you please explain why
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
What does sendmsg(2) say what to include? What about writev(2)? (the
latter, on Linux, says that sys/uio.h is indeed the correct header)
--
nosy: +loewis
___
Python tracker <[EMAIL
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Looks fine to me. Please apply (don't forget a NEWS entry).
--
nosy: +loewis
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> the compiling strategy for Python (IIRC) is to compile everything,
> including modules that will never work, and use compiler errors as a
> signal to not include a module in the result.
I don't think this c
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Somewhere along the way the calculation of the architecture string got
> messed up, resulting in the current situation. That is, the current
> situation is not as designed by the original author of the universal
> b
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Kristjan, you suggested this issue for consideration for 2.5.3.
Is there an actual patch to apply?
If not, the issue should get forwarded to 2.7 (and then to 2.8, and so
on, until somebody actually comes up with a patch).
-
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Kristján, you suggested this patch to be considered for 2.5.3.
It seems the patch is incorrect. Can you provide a correct one?
--
nosy: +loewis
versions: +Python 2.5.3
___
Python tracker &
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Martin meaning of target and host is different.
> There is no reason to use "Canadian Cross": build->host->target.
> It is about more simple cross-compilation case: build->host.
Terminology issu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> What about to substitute UNICODE macro as example with RAWUNICODE in the
> source ?
That would work as well. As it stands, the macro names are equivalent to
the ones in pickle.py, which is a useful property to have. So I'
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, un-targetting it from 2.5.3 for now.
--
versions: -Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, un-targetting this from 2.5.3 then.
Usage of IsUNCRoot disappeared as part of r42230, which dropped usage of
the C library for stat implementations. This only affects os.stat,
though, so I don't see the relation to this issu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is a known problem; see the GC discussions in June for an example, e.g.
http://mail.python.org/pipermail/python-dev/2008-June/080579.html
--
nosy: +loewis
___
Python tracker &
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> It is not documented anywhere but in the code
These also appear in file names of bdist commands, right? So I think it
should be documented.
> We (Bob Ippolitto and I) had some discussion about the architecture
> strings
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is a patch. I also include a test case, which is intended to go
into the Demo directory.
--
keywords: +patch
Added file: http://bugs.python.org/file11744/build_py.diff
___
Python t
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
keywords: +needs review
Added file: http://bugs.python.org/file11745/test2to3.tar.gz
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I agree that a static buffer should be used. I think calling it in a
loop is overkill. Instead, if an overrun occurs, adding "(truncated)"
should be good enough. I could find only a single caller that doesn't
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> If the CE can't work with char why the compiler don't threat strings as
> wide characters always ?
I think this question is pointless - we don't have the power to change
how CE works. You might question wheth
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> (And I thought that manifests and side-by-side assemblies were
> supposed to solve the "DLL hell")
I'm now convinced that they make things worse, to the degree that
certain deployments that used to work cannot
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> "Pointless" question is for compiler flags and is not related with the OS.
I don't think the compiler has any such flag that you might consider
useful. Do you have a specific flag in mind?
__
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
They should be present in the installation (and I believe "make install"
will create them).
Whether or not they are included in the source distribution is not
important, IMO. I'm puzzled that they are modifed - t
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'm tempted to close this as "won't fix".
--
nosy: +loewis
resolution: -> wont fix
___
Python tracker <[EMAIL PROTECTED]>
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I couldn't found where python C-code use so called "TCHAR meaning" and
> the first sentence from comment in Ulrich patch looks irrelevant to the
> issue.
I was confused by Ulrich's terminology at first,
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
title: use of TCHAR under win32 -> UNICODE macro in cPickle conflicts with
Windows define
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> If the python switch to W functions then the issue will be resolved.
Python should use the *W functions wherever possible.
> Without general switch to W functions and to wide strings we need to
> convert every time from
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4104>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
r61109 became obsolete when I added support for the merge module; here
is a patch that fixes this. An installer demonstrating the change is
available from
http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-2.7.141
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the confirmation. Committed as r66881, r66882, and r66883.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis added the comment:
I'm worried about this "on behalf of" contribution. Does Stuart Shelton
actually approve this contribution? Would he be willing to sign a contributor
agreement?
--
nosy: +loewis
___
Python
Martin v. Löwis added the comment:
Same issue as with 7718: I'm worried about this "on behalf of" contribution.
Does Stuart Shelton actually approve this contribution? Would he be willing to
sign a contributor agreement?
-
Martin v. Löwis added the comment:
I think the patch in its current form is then, unfortunately, not acceptable -
unless Stuart Shelton actually signs a contributor agreement. I don't know what
makes you believe that he actually meant to contribute the code to Python, but
I just don&#
Changes by Martin v. Löwis :
--
resolution: postponed -> rejected
___
Python tracker
<http://bugs.python.org/issue7718>
___
___
Python-bugs-list mailing list
Un
Martin v. Löwis added the comment:
The buildslaves most definitely will *not* execute any code under administrator
privileges; doing so would put the machine under a serious threat.
The tests should be skipped if the privilege is not held; it may be reasonable
to grant the privilege to the
Martin v. Löwis added the comment:
I think dropping the spaces after the function names is fine in this case; the
module is inconsistent in this matter.
--
nosy: +loewis
status: pending -> open
___
Python tracker
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
> Given that there is a specific permission that can be assigned to the
> buildslave user, it seems appropriate that the tests that attempt to
> create symlinks should fail if the user does not have that
> permission.
No, the test should *not* fai
Martin v. Löwis added the comment:
> If there is a skip test, it should be dependent on the specific permission
> required.
Terminology: it's a "privilege", not a "permission". Permissions (in
Windows) are stored in ACLs on objects, granted by the owner of the
Martin v. Löwis added the comment:
Can you propose a patch?
I personally consider this not worth the effort. Unless there is a DNS problem,
this cases shouldn't really be noticable, as the socket module will immediately
report that IPv6 is not supported (without even consulting the oper
Martin v. Löwis added the comment:
I'd also be curious why it takes a second to open /etc/localtime. That sounds
like a bug in the C library, or a mismanaged system.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
I'm closing this as "won't fix". If there is a need to run specific tests in
specific ways, it is best to check in code that does it as desired. If it is
then unacceptable to run that change on all slaves, a branch can be created,
and
Martin v. Löwis added the comment:
I think the bug here is really in the application, which makes a system call to
fuse and the fuse callback in the same process. This isn't supported, and IMO
doesn't need to be. Python makes no promises that it will accept callbacks
while a syst
Martin v. Löwis added the comment:
One relevant difference may be the change to the fork semantics in Solaris 10:
fork() now means the same as fork1(). Before, fork() meant the same as
forkall(), unless the applications was linked with -lpthread, in which case
fork() also meant fork1(). See
Changes by Martin v. Löwis :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue7621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
Generate a message.
--
___
Python tracker
<http://bugs.python.org/issue7621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
> Generate a message.
Reply to it.
--
___
Python tracker
<http://bugs.python.org/issue7621>
___
___
Python-bugs-list mai
Martin v. Löwis added the comment:
A patch has good chances of getting accepted (eventually; it may take several
months or years). Test cases and documentation changes should be included.
Supporting generic socket addresses can't work (IMO): how could Python possibly
know how to map a P
Martin v. Löwis added the comment:
> In my patch I wanted to reduce the effect on systems where forking in
> thread is working (eg. linux), that's the reason why I added
> "(defined (__SVR4) && defined (__sun)".
I think that
New submission from Martin v. Löwis :
For the attached script, 2to3 reports
File "/tmp/lib/python3.1/lib2to3/pytree.py", line 135, in replace
assert self.parent is not None, str(self)
AssertionError: def a(self):
pass
This was originally discovered for twisted/
Changes by Martin v. Löwis :
--
versions: -Python 2.5
___
Python tracker
<http://bugs.python.org/issue7812>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
Why do you think this is a bug? It's the whole point of pythonw.exe to not open
any window.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/i
Changes by Martin v. Löwis :
--
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7165>
___
___
Martin v. Löwis added the comment:
This switch is intentionally not documented.
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Martin v. Löwis added the comment:
I have now tried reproducing the problem, and still failed to. I downloaded,
from http://sourceforge.net/projects/mingw-w64/files/, the distribution
mingw-w32-bin_i686-mingw_20100123_sezero.zip.
With this, I get
c:\cygwin\mingw64\bin\gcc.exe -mno-cygwin
Martin v. Löwis added the comment:
I don't think changing anything is necessary here. Having the option listed
gives the curious a chance to discover a piece of Python history :-)
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed in r77900.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Martin v. Löwis added the comment:
Not sure what your use case is, but I always call the refactor method of my
subclassed RefactoringTool, instead of calling main. See
distutils.util.run_2to3 for an example (and
distutils.command.build_py.build_py_2to3 for an application of that
Martin v. Löwis added the comment:
This is fixed in Python 3.
I think it is (another) bug that it accepts array objects; it should reject
them with the same error. OTOH, recv_into should use "w*".
--
nosy: +loewis
___
Python trac
Changes by Martin v. Löwis :
--
components: +2to3 (2.x to 3.0 conversion tool)
___
Python tracker
<http://bugs.python.org/issue2454>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
If you meant to propose a patch that does caching, you should include the
actual caching code in the patch.
--
___
Python tracker
<http://bugs.python.org/issue7
Martin v. Löwis added the comment:
Please submit a contributor agreement, see http://www.python.org/psf/contrib/
I'm still not clear on what the specific use case is: how *exactly* are you
going to run 2to3 when you have that patch integrated? In particular, where do
you put the output
Martin v. Löwis added the comment:
No, cmp is not missing. It's intentionally removed, and won't come back. So
closing this as "won't fix".
I'm not sure what you are aiming at with the universal key function; if you
want a key function that guaran
Martin v. Löwis added the comment:
I think this should be discussed on python-dev (I believe it *has* been
discussed on python-dev, I just don't remember the outcome). Creating fixers is
not feasible, I think. In any case, it's an issue different from the one you
Martin v. Löwis added the comment:
This doesn't look right. IIUC, wininst.exe loads python26.dll, which in turn
loads pywintypes.dll. So it should be python26.dll which loads the CRT.
IIUC, wininst.exe is linked statically, precisely to avoid a dependency on the
CRT ass
Martin v. Löwis added the comment:
I fail to see the point. This bug was fixed in Python 3. Why risk breaking
something in the last 2.x release?
--
___
Python tracker
<http://bugs.python.org/issue7
Martin v. Löwis added the comment:
I'm +0 on such a change - I don't think it makes anything better (it will only
cause more users asking what this is, why it was added, and demand that
something should be done about it).
Feel free to commit it, anyway.
--
assignee: loewi
Martin v. Löwis added the comment:
That iconv supports it is not convincing, IMO. Do you have other sources (like
tables in the web somewhere) that support your request?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue7
Martin v. Löwis added the comment:
In particular, the Unicode consortium mapping table, now at
http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT
doesn't map f9d8 to anything; the current version of that table (in unihan.zip)
has these mappings for U+88CF:
U
Martin v. Löwis added the comment:
perky, what do you think?
--
assignee: -> hyeshik.chang
nosy: +hyeshik.chang
___
Python tracker
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
Would you like to work on a patch?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue7889>
___
___
Python-bug
Martin v. Löwis added the comment:
This is not a bug in Python, but in your code. sys.setdefaultencoding is only
supported when setting the default encoding to either latin-1, or ascii, or
'undefined'. Setting it to any other value will have undesirable consequences
like the one
1501 - 1600 of 4778 matches
Mail list logo
