Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1345>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1347>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1349>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1350>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I'm skeptical:
- If you add getsize, why not getlastchangeddate, getowner, getpermissions?
- in general, streams (which really is the interface for file-like
objects) don't have the notion of "size"; only some do.
- what is the purpose of
Martin v. Löwis added the comment:
Yes, the documentation should be changed. I feel sorry that you've
wasted your time.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Martin v. Löwis added the comment:
Indeed, this tracker is not about obtaining support. It is a place for
you to help us, not for us to help you.
If you want to help, please report the precise URL, and compute and
report the md5sum of the file you downloaded.
--
nosy: +loewis
Martin v. Löwis added the comment:
Thanks for the report. Fixed in r58705.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1356>
__
___
Martin v. Löwis added the comment:
Can you please also attach config.log (perhaps compressed)?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I fail to see the bug. The documentation is correct as it stands, ie.
None is *not* displayed normally. IOW, writing is normally suppressed.
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
T
Martin v. Löwis added the comment:
There is an autoconf test that tries to compile
| #include
| int
| main ()
| {
| setpgrp(0,0);
| ;
| return 0;
| }
(with many additional defines - see config.log.gz). This file compiles
with the error message
conftest.c:185: error: too many arguments to
Martin v. Löwis added the comment:
What compiler did you use? Can you please attach the compressed config.log?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
Where is the patch?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1365>
__
___
Python-bugs-list
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1374>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I just created
http://wiki.python.org/moin/TrackerAccessControl
which specifies all permissions in the tracker in detail.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
> Guido van Rossum added the comment:
>
>> http://wiki.python.org/moin/TrackerAccessControl
>>
>> which specifies all permissions in the tracker in detail.
>
> Is it so that Anonymous < User < Developer < Coordinator?
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1378>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1379>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
Can you propose a patch?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1381>
__
___
Python-bugs-
Martin v. Löwis added the comment:
It would be ok if a test is only run on a system with IEEE floats, and
skipped elsewhere. For all practical purposes, Python assumes that all
systems have IEEE float.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1383>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1385>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
That's not a bug in Python, but in your script. You should not pass such
a string to createComment.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Martin v. Löwis added the comment:
It's not a bug in the DOM implementation, as createCommment does not
specify an exception in this case. It may be a bug in the W3 DOM
specification; please report that to the W3 consortium.
It's not a bug in toxml, which should always serialize the D
Martin v. Löwis added the comment:
I'm not willing to change minidom unless there is precedence of how to
deal with this case. So can you find DOM implementations in other
languages that meet the DOM spec an still reject your code?
__
Tracker <[EMAIL P
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1394>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
Would anybody want to provide a patch, then?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1390>
__
___
Python-bugs-list
Martin v. Löwis added the comment:
It may the intention that these functions may raise exceptions in other
cases as well - but can you also support that possibility from the text
of the DOM spec itself?
Adding an exception there may break existing applications, which already
have except clauses
Martin v. Löwis added the comment:
The standard procedure for an incompatible change would be to add such a
parameter to 2.6, and then change the default behavior in 2.7 (or rather
3.1). Of course, people will not notice the change in 2.6, and then be
surprised as much about the default change
Changes by Martin v. Löwis:
--
severity: urgent -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1411>
__
___
Python-bugs-list mailing li
Martin v. Löwis added the comment:
As now should be clear, there really is no bug here.
Notice that you can also write
1 .__str__()
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis added the comment:
See
http://www.python.org/doc/2.5/ref/whitespace.html
which says that you can put spaces between arbitrary tokens, and
http://www.python.org/doc/2.5/ref/attribute-references.html
which says that all of primary, ".", and identifier are separate to
Martin v. Löwis added the comment:
Ok, I'm rejecting it now based on the YAGNI argument Guido brought up,
and based on my own concerns.
--
resolution: -> rejected
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis added the comment:
Ok. Closing it as third-party.
--
resolution: -> invalid
status: open -> closed
versions: +3rd party -Python 2.5
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed in r58940.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
I think this patch is wrong. Python source code is inherently text, so
generate_tokens should decode the input, rather than operating on bytes.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r58941.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
This error message is not produced by the Python MSI file, but by
Windows installer itself. It computes the set of files that we are about
to install, which includes the Microsoft C Runtime DLL. I guess that
this file is also in use by Explorer.
It is safe to
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1431>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
As Guido says: this is by design. The Unicode type doesn't really
support storage of surrogates; so don't use it for that.
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
__
Tracker &
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1442>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I'm rejecting this patch, for several reasons:
- it addresses too many issues in a single patch. Separate bug reports
need to be submitted for independent issues.
- for each issue, it fails to explain what the problem is. For example,
"some lib
Martin v. Löwis added the comment:
tiran is correct. distutils should work without having to invoke a VS
build environment. Relying on that environment would have worked way
back to VC6 and earlier, but it would reduce the ease of use of distutils.
Rejecting the patch.
--
nosy: +loewis
Martin v. Löwis added the comment:
I'm opposed to this patch. Any change to the MSI build process should
only be made when/after the default compiler for Python is changed. That
needs to be discussed on python-dev first, and I hope that the new build
infrastructure will *not* use the PCb
Martin v. Löwis added the comment:
One issue that also needs discussion is the structure of the build
directory. It could temporarily be PCbuild9, but in the long run, it
should replace PCbuild. Apart from that, the issue is whether there
should be a flat structure as it is currently in PCbuild
Martin v. Löwis added the comment:
In all versions of make, "make CFLAGS=..." should work fine (although
that's not an environment variable).
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://b
Martin v. Löwis added the comment:
> Any "standard" way to add custom compilation flags?.
See the README. Set OPT to influence the optimization flags;
set EXTRA_CFLAGS otherwise.
__
Tracker <[EMAIL PROTECTED]>
<http://bug
Martin v. Löwis added the comment:
There is always the debate whether distutils might be repackaged and
backported to older Python releases, therefore people hesitate to remove
support for older versions.
As for finding it in the registry: are you sure it has no registry
settings anymore? I
Martin v. Löwis added the comment:
As another note: you shouldn't remove support code for Itanium. Even
though no Itanium binaries will be produced at the releases, I see no
reason to rip the code out - people with Itanium machines should still
be able to build Python, with some e
Martin v. Löwis added the comment:
Ok. Running vsvars is fine, then.
The change to get_build_architecture is broken in another way: as it
parses the architecture out of sys.version, you still get Intel, not x86
(unless you also change PC/pyconfig.h - which may break code that relies
on the
Changes by Martin v. Löwis:
--
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1455>
__
___
Python-bugs-list mailing list
Uns
Martin v. Löwis added the comment:
The reason this is not part of the Windows installer is twofold:
a) nobody ever thought of making it so, ever since the htmlhelp was
added, and
b) no code was contributed to add such a procedure to the Windows installer.
Contributions are welcome, although I
Martin v. Löwis added the comment:
kevinwatters: don't bother fixing msi.py. I'll update it whenever I make
a release; there is little point in updating it in-between.
--
assignee: -> loewis
nosy: +loewis
__
Tracker <[EMAIL P
Martin v. Löwis added the comment:
Did you test the change for VS 2003? In my MSMDir
(C:\Programme\Gemeinsame Dateien\Merge Modules), I only have the
following files
GDIPlus.msm
msmask32_X86.msm
msmask32_X86_ENU.msm
VB_Control_mschart_RTL_X86_---.msm
VB_Control_mschart_RTL_X86_ENU.msm
Martin v. Löwis added the comment:
Closing because of lack of activity.
--
resolution: -> works for me
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Thanks for pointing that out. The MSI build needs to be taught to pick
them up. If I seemingly don't find the time, feel free to contribute a
patch.
--
assignee: -> loewis
nosy: +loewis
__
Tracker <[EMAI
Martin v. Löwis added the comment:
Thanks for the patch. It looked good, so I committed it as r59066. Let's
see whether the buildbot picks it up correctly.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Martin v. Löwis added the comment:
So what's the definition of struct winsize on these systems?
Also, why do you think this is a bug in Python? AFAICT, the specific
ioctl call does not occur in Python, but in your own code.
--
nosy: +loewis
resolution: -> invalid
stat
Martin v. Löwis added the comment:
Please don't use the FileSystemEncoding on Windows for sys.path items.
Instead, it should use the wide API to perform all system calls. Py3k
shouldn't ever use the file system encoding for anything on Windows.
__
Track
Martin v. Löwis added the comment:
It seems that this patch has broken a lot of buildbots, e.g.
http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/2625/step-test/0
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Martin v. Löwis added the comment:
See also Tools/buildbot/buildmsi.bat. With cygwin installed, building
the documentation is as simple as
bash.exe -c 'cd Doc;make PYTHON=python2.5 update htmlhelp'
"%ProgramFiles%\HTML Help Workshop\hhc.exe" Doc\build\htmlhelp\pydoc.
New submission from Martin v. Löwis:
I believe it is safe to drop all the _EXPORTS macros (MMAP_EXPORTS,
WINSOUND_EXPORRTS etc) from all projects; atleast I cannot see any
reason for having them. Some are clearly bogus, e.g. unicodedata and
test_capi both define MMAP_EXPORTS, _socket defines
Martin v. Löwis added the comment:
See the MSDN for details. IIUC:
- _WIN32 is defined by the compiler, always, unless the platform is
WIN16 (which is no longer supported). It is even defined on Win64 (where
the compiler also defines _WIN64). So there should be no need to defined
it explicitly
Martin v. Löwis added the comment:
It's tedious to require users to invoke such a shell, and it would
produce an endless flood of support requests if we made that a
requirement. So requiring to build in such a shell is absolutely
unacceptable.
__
Tracker &l
Changes by Martin v. Löwis:
--
assignee: -> tiran
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1476>
__
___
Python-bugs-list mailing list
Uns
Martin v. Löwis added the comment:
Why do you think this is a bug? 08 really is a syntax error, and 010
really means 8.
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Can you provide a setup.py that allows to reproduce this error?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1285>
__
___
New submission from Martin v. Löwis:
Can you propose a specific wording?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1494>
__
___
Martin v. Löwis added the comment:
Thanks. I committed something like that as 59176.
Notice that the precise semantics of all operations is specified in the
DOM itself,
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html
which says
Adds the node newChild to the end of the list
Martin v. Löwis added the comment:
I verified the installer; this problem is now fixed.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Can you please be specific what compilers and systems you are talking
about? I doubt your statements hold for *all* native UNIX compilers. In
particular, .s files should be compiled with as, not cc, on the UNIX
systems I'm familiar with, but that won'
Martin v. Löwis added the comment:
> The quad-precision float would be highly portable
Larry, please stop this discussion in this issue. I believe
a PEP would be needed, and would likely be rejected because
of the very very very long list of issues that can't be
resolved. I think you s
Martin v. Löwis added the comment:
> As I wrote before, I would prefer to keep the same number of fields
> in the Python structure and in the C structure, but I don't have a
> strong opinion on this choice.
I'm with Larry - exposing time fields as structured record
Martin v. Löwis added the comment:
Notice that this "signed overflow" issue is also tracked as #1621. I don't mind
keeping this issue open, though - it's unlikely that #1621 will be fixed within
this decade. unless somebody does some heroic effort.
Martin v. Löwis added the comment:
Nadeem, I started reviewing this path, but now stopped since the patch I
reviewed isn't available anymore. Please let us know when the patch has a state
where you don't plan to make more changes.
--
Martin v. Löwis added the comment:
> I encountered more failures in module build with my
> HP-UX ANSI C Compiler versus gcc. I wonder why.
That's really simple to answer. HP-UX is not well supported. You are pretty
much on your own.
--
no
Martin v. Löwis added the comment:
Tom: it's intentional that .title() doesn't use traditional word break
algorithms. In 2.x, "foo3bar".title() is "Foo3Bar", i.e. the 3 counts as a word
end. So neither UTS#18 \w nor UAX#29 apply. So in UTS#18 terminology, .title
Martin v. Löwis added the comment:
Can you please run
msiexec /i python2.7.2.msi /l*v python.log
and compress and attach the resulting python.log?
I'm skeptical though that we will be able to do anything about this issue.
--
___
Python tr
Martin v. Löwis added the comment:
Ok, closing this as "won't fix", them.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bu
Martin v. Löwis added the comment:
You said "I can maintain the patch for future releases". This sounds like a
reasonable solution: you keep maintaining the patch; if you want python.org to
link to your patch, we can certainly arrange that. By the "no minority
platforms&quo
Martin v. Löwis added the comment:
Do we consider these overflows as bugs in Python, or do we declare that we
expect compilers to "do the right thing" for the bug fix releases (i.e. care
only about the default branch). I'd personally vote for the latter - i.e. don'
Martin v. Löwis added the comment:
Sounds all fine to me.
As the PEP specifies, all deprecation will only be on paper for now, not in the
code. Adding PyUnicode_GetMax to the list sounds fine to me as well.
--
___
Python tracker
<h
Martin v. Löwis added the comment:
I propose to use a better lookup algorithm using binary search, and then
integrate the NamedSequences into this as well. The search result could be a
record
struct {
char *name;
int len;
Py_UCS4 chars[3]; /* no sequence is more than 3 chars
Martin v. Löwis added the comment:
I agree that the codec shouldn't "decode" unicode strings. However, the
operation performed is still meaningful: users may type ACE
(ascii-compatibly-encoded) DNS names into a user interface, and the application
may then represent this as a &
Martin v. Löwis added the comment:
> Martin, do you think that str.title() should follow the Unicode standard?
I don't think that "follow the Unicode standard" has any meaning in this
context: the Unicode standard doesn't specify (AFAIK) what a .title()
method in a prog
Martin v. Löwis added the comment:
> * Word characters are Alphabetic + Mn+Mc+Me + Nd + Pc.
Where did you get that definition from? UTS#18 defines
"", which is Alphabetic + U+200C + U+200D
(i.e. not including marks, but including those
> I think you are looking for here are
Martin v. Löwis added the comment:
Thanks for the patch!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
I like "Python 2" more than "2.x".
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13086>
___
__
Martin v. Löwis added the comment:
>> As for terminology: I think the documentation should continue to
>> speak about "words" and "letters", and then define what is meant
>> in this context. It's not that the Unicode consortium invented
>> the
Martin v. Löwis added the comment:
> Does that sound fine?
Yes, that's fine as well.
--
title: \N{...} neglects formal aliases and named sequences from Unicode
charnames namespace -> \N{...} neglects formal aliases and named sequences from
Unicode charname
Martin v. Löwis added the comment:
> You may wish unicode.name() to return the alias in preference, however.
-1. .name() is documented (and users familiar with it expect it) as
returning the name of the character from the UCD.
It doesn't really matter much to me if it's non-se
Martin v. Löwis added the comment:
> It's not a container type, just a small C struct that
> gets allocated on the stack. Think of it as a library, like stringlib.
That's what I call a container type: a structure with a library :-)
> That's another possibility. But we
Martin v. Löwis added the comment:
>> There are no official English titling rules and as you noted,
>> publishers vary.
>
> If there aren't any rules, then how come all book and movie titles always
> look the same? :)
Can we please leave the English language out
Martin v. Löwis added the comment:
The patch needs to take versioning into account. It seems that NamedSequences
where added in 4.1, and NameAliases in 5.0. So for the moment, when using 3.2
(i.e. when self is not NULL), it is fine to lookup neither. Please put an
assertion into
Martin v. Löwis added the comment:
> The main underlying problem is that the internal macros are defined in a
> way that made sense a long time ago, but no longer do ever since (for
> example) the Unicode lowercase property stopped being synonymous with
> GC=Ll and started also i
Martin v. Löwis added the comment:
> - liblzma can't be compiled by Visual Studio: too many C99 isms,
> mostly variables declared in the middle of a block. It's doable for
> sure, but it's a lot of work.
I'd be in favor of doing so, and then feeding patches up
Martin v. Löwis added the comment:
> Based on Amaury's report, I would suggest going forward integrating
> the xz module for configure-based systems, and letting someone else
> handle Windows integration later if a solution is found.
-1000. I feel quite strongly that this shoul
Martin v. Löwis added the comment:
Am 04.10.11 19:08, schrieb Antoine Pitrou:
>
> Antoine Pitrou added the comment:
>
>>> Based on Amaury's report, I would suggest going forward integrating
>>> the xz module for configure-based systems, and letting someone els
Martin v. Löwis added the comment:
> Not really. xz is becoming a defacto standard under Linux (and perhaps
> other free Unices) while I guess it is marginal under Windows.
> We have other system-specific functionality, and nobody sees it as a bad
> thing.
That's because al
Martin v. Löwis added the comment:
> That said, I wonder what happens in Windows with the BZ2 module, for instance
> :-?.
External code currently lives at
http://svn.python.org/projects/external/. The build process gets it from
there, and we may
have local modifications to libraries
201 - 300 of 4778 matches
Mail list logo
