Martin v. Löwis added the comment:
Am 06.10.11 13:01, schrieb Nadeem Vawda:
>
> Nadeem Vawda added the comment:
>
> Wow, this discussion has gotten quite busy while I've been travelling...
>
> Martin, could you explain what the problems are with bundling a precompil
Martin v. Löwis added the comment:
Marc-Andre: gcc will normally not unroll loops, unless -funroll-loops is given
on the command line. Then, it will unroll many loops, and do so with 8
iterations per outer loop. This typically causes significant code bloat, which
is why unrolling is normally
Martin v. Löwis added the comment:
It would be interesting to see how often the "bad" case triggers, i.e. that a
write-only stringio sees any of the other methods invoked at all.
As a special case, you may consider that .truncate(0) doesn't really need to
realize the buffer
Martin v. Löwis added the comment:
If you don't use git-style diffs, Rietveld will much better accommodate patches
that don't apply to tip cleanly. Unfortunately, hg git-style diffs don't
indicate the base revision, so Rietveld guesses that the base line is tip, and
then fail
Martin v. Löwis added the comment:
>>> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS
>> It seems that the Windows version at least is not thread-safe. If so, you
>> would need an LZMA lock when releasing the GIL.
>
> Does the class need to be thread-safe, though
Martin v. Löwis added the comment:
>> Correct. I copied the algorithm from _io.FileIO, under the assumption
>> that there was a reason for not using a simpler O(n log n) doubling
>> strategy. Do you know of any reason for this? Or is it safe to ignore it?
>
> I don'
Martin v. Löwis added the comment:
I think the >1 character sizes are overly complex in this patch, and still
memchr isn't typically used for them. So I suggest to simplify the code and
restrict it to 1-byte chars only.
--
___
Python
Martin v. Löwis added the comment:
I have imported xz-5.0.3 into the externals repository now.
--
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Martin v. Löwis added the comment:
> I would rather propose to simplify the needle heuristic and only use it
> when the lower byte is non-zero. A properly optimized memchr() (as in
> the glibc / gcc) is definitely faster than our naïve loop.
That would be fine as well. Not sure if a h
Martin v. Löwis added the comment:
I think the WideCharToMultibyte approach is just incorrect.
I'm -1 on using wcswidth, though. We already have unicodedata.east_asian_width,
which implements http://unicode.org/reports/tr11/
The outcomes of this function are these:
- F: full-width, wi
Martin v. Löwis added the comment:
The problem is that the config file is parsed using GetPrivateProfileString,
and the result is then passed to TextOut, SetDlgItemText, CreateWindow, etc.
all of which are defined to accept MBCS strings. I agree that this can't work
correctly in the ge
Martin v. Löwis added the comment:
Corey, Sebastian: VS 2010 is not supported. So failure to work correctly is not
a bug in Python.
--
___
Python tracker
<http://bugs.python.org/issue4
Martin v. Löwis added the comment:
The error message told you exactly what the problem is. Your source file does
not conform to PEP 263. The PEP also explains why this applies to comments as
well: because the entire file gets decoded according to the source encoding,
and parsing (including
Martin v. Löwis added the comment:
> Do we need to keep backward compatibility if we change the format of the
> config
> data? Or wininst-xx.exe are only usable with trailing config data in the .exe
> file?
The wininst.exe belongs to the version of distutils it is released wi
Martin v. Löwis added the comment:
-1 on auto-building. The header needed may not be available on the build
platform, if it is not normally needed to build Python.
--
___
Python tracker
<http://bugs.python.org/issue12
Martin v. Löwis added the comment:
Am 17.10.2011 06:22, schrieb Phillip Feldman:
> This is a fine example of the so-called "is-ought" controversy.
Wrong. This has nothing to do with desired and factual. A bug, by
definition, is a deviation from the specification. This is not a
Martin v. Löwis added the comment:
>> I'm -1 on using wcswidth, though.
>
> When you write text into a console on Linux (e.g. displayed by
> gnome-terminal or konsole), I suppose that wcswidth() can be used to
> compute the width of a line. It would help to fix #2382.
&g
Martin v. Löwis added the comment:
Can you please provide a test case? What exact source code you are using, and
what exact result are you getting? Attach those pieces as files.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.
Martin v. Löwis added the comment:
I think this issue urgently needs a scope defined. What *exactly* is it that
you want to achieve? If it's merely being able to compile Python with VS 2010,
many of the proposed changes are unnecessary.
If you propose that the patch should be used to re
Martin v. Löwis added the comment:
I think the reported exception type is incorrect. Given that the error message
is 'Locale must be None, a string, or an iterable of two strings -- language
code, encoding.', it very much sounds like a TypeError is being reported here.
So I think
Martin v. Löwis added the comment:
> Maybe we should return TypeError with the same message then? That
> would require some modification of documentation though, as it
> states: "If the modification of the locale fails, the exception Error
> is raised.".
No, any operatio
Martin v. Löwis added the comment:
> Thanks for clarification! I see the problem now. So if I get this
> correctly we should change the _build_localename to raise TypeError?
Yes, that's what I'm proposing.
> If the given locale is in wrong format, we'll get TypeError,
Martin v. Löwis added the comment:
We shouldn't use the MS codec if we have our own, as they may differ.
As for the 65001 bug: is that actually solved by this codec?
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
> Which part of the changes do you consider unnecessary?
All the parts dealing with packaging, in particular Tools/msi.
> I understand there is a feature freeze on this branch (event though
> the changes in this case are well localized and not intru
Martin v. Löwis added the comment:
>> As for the 65001 bug: is that actually solved by this codec?
>
> Sorry, which bug?
#6501 and friends (isn't it interesting that the issue of code page
65001 is reported as bug 6501?)
--
_
Martin v. Löwis added the comment:
Victor, please accept that this entire infrastructure was originally added
because there was a need for it, and the need did not go away. It's probably
relevant only for a minority of applications, but you would make this
minority's lifes
Martin v. Löwis added the comment:
> If the installation process adds the "Open with IDLE" entry, it should do it
> again when you reinstall
Rather than going through reinstallation, go to "Add and Remove
Programs", find Python 3.2, and select "Repair instal
Changes by Martin v. Löwis :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13221>
___
___
Python-bugs-
Martin v. Löwis added the comment:
The patch looks fine to me. However, I don't think it meets Charles-François'
requirement of moving the constants into an individual module. Rather than
living in the unmanageable plat-XXX, they now live in the unmanageable
posixmodule.c...
-
Martin v. Löwis added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue12753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
> Maybe we should change the build system to always regenerate the files
> or add something to automation that regenerates the AST C file every
> time.
Most definitely not. It is very deliberate that asdl_c.py is only
invoked when the ASDL sourc
Martin v. Löwis added the comment:
Before the release, we should consider whether we can drop these functions
altogether.
--
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
Am 23.10.2011 20:33, schrieb Meador Inge:
>
> Meador Inge added the comment:
>
>> Most definitely not. It is very deliberate that asdl_c.py is only
>> invoked when the ASDL sources change. Otherwise, having Python installed
>> w
Martin v. Löwis added the comment:
So it's not a bug at all, right?
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.
Martin v. Löwis added the comment:
LGTM.
--
___
Python tracker
<http://bugs.python.org/issue13251>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
I think there is a value to use the very same function names in the posix
module as in the posix API. The posix API (and C in general) is also flat, and
uses the prefix convention. People who look at the function lists will know to
ignore blocks of
Martin v. Löwis added the comment:
This issue is getting messy. I declare that this issue is *only* about the
original problem reported in msg146031. When that is fixed, this issue will be
closed, and any further issues need to be reported separately.
As for the original problem, ISTM that
Martin v. Löwis added the comment:
As a policy, we will not rely on C++ destructors for cleanup. There are really
two issues here: "global" locks, and module-specific locks.
The global locks can and should be released in Py_Finalize, with no API change.
Antoine's patch looks g
Martin v. Löwis added the comment:
Ezio: your patch is fine for 3.3. I agree it's not a bug fix.
I propose the following additional changes, though:
- the name of the root element should be lower-case in the DOCTYPE declaration.
- DEFAULT_ERROR_MESSAGE should get an opening html tag.
Martin v. Löwis added the comment:
Changing the error message sounds fine to me.
People in need of the feature should lobby their system vendors to provide a
Tcl build that uses a 32-bit Tcl_UniChar. Not sure whether it would actually
render the string correctly, but at least it would be
Martin v. Löwis added the comment:
ita1024: please don't post to closed issues; your message here will be ignored.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
I declare the original issue closed - there is no reason to switch to HTML 5 in
this code.
There are side issues, such as the HTML 3.2 perhaps being incorrect; people who
want to commit patches in that respect can just go ahead
Martin v. Löwis added the comment:
> Note we only really see the effect if we make sure that gcc
> isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
> is SO important on gcc builds!
I'd rather infer the opposite: given how GCC generates
Martin v. Löwis added the comment:
Ok, closing the issue.
--
___
Python tracker
<http://bugs.python.org/issue13279>
___
___
Python-bugs-list mailing list
Unsub
Changes by Martin v. Löwis :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13279>
___
___
Python-bugs-
Martin v. Löwis added the comment:
> I ran into an application that responded with two www-authenticate
> challenges to an HTTP request. First, it sends a standard Basic
> authentication challenge and then it also returns a www-authenticate
> header referencing another scheme.
Martin v. Löwis added the comment:
So what do you propose to do? RFC 2617 specifies
The user agent MUST choose to use one of the challenges with the
strongest auth-scheme it understands and request credentials from the
user based upon that challenge
Martin v. Löwis added the comment:
RFC 2152 talks about encoding 16-bit unicode, and clarifies
Surrogate pairs (UTF-16) are converted by treating each half
of the pair as a separate 16 bit quantity (i.e., no special
treatment).
So lone surrogates clearly should be supported.
This text
Martin v. Löwis added the comment:
Would you like to provide a patch?
--
___
Python tracker
<http://bugs.python.org/issue13323>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
I'm not sure whether the wording is good English, but apart from that, the
patch looks fine.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
Most likely, you are using a 32-bit Python on a 64-bit Windows. 32-bit programs
can't access c:\windows\system32, as that will contain the 64-bit DLLs.
Instead, access is redirected to c:\windows\syswow64.
Please confirm whether or not this is the case
Martin v. Löwis added the comment:
+1
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13350>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
I think the patch currently lacks a lot of symbolic constants; see my review.
--
___
Python tracker
<http://bugs.python.org/issue7
Martin v. Löwis added the comment:
Not having tests for the control messages is fine with me - we don't need to
test Linux, but Python.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
I fail to see the issue. What exactly is the problem with the warning? It looks
all consistent and helpful to me.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
> Often sequences or sets have heterogeneous keys, mixing and
> , and in this case there's no easy way to work with them
> without raising this UnicodeWarning.
That's a bug in the application. You must not mix byte strings
and unicode st
Martin v. Löwis added the comment:
skreft: I can see nothing wrong by having a website that lists PEP 8 violations
in the standard library - feel free to create one on wiki.python.org.
Your preferred solution of having automated tests is not feasible. Taking
punycode.py (sic) as an example
Martin v. Löwis added the comment:
skreft: since you were asking for a reason why the code looks the way it looks
- the code in many cases predates the introduction of iterkeys and friends.
I personally find the names iterkeys/itervalues/iteritems fairly ugly, and
rather avoid them for
Martin v. Löwis added the comment:
Closing the report as invalid then.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> Your patch about SSLContext is great! But what can we do about python 2.x?
Adding new features to Python 2.7 is certainly not an option.
> what do you think about a DeprecationWarning at runtime?
What API exactly should this deprecate?
--
Martin v. Löwis added the comment:
Why was the change necessary? unicode_decode_call_errorhandler shouldn't be
called with WSTR strings (i.e. it is only intended to support ready strings).
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
AFAICT, this code was introduced in 0337dad8403e, implementing PEP 293 (see
#432401). The intention clearly was what Stefan figured out: compute the list
of unencodable characters, to pass the longest run of unencodable characters to
the error handler
Martin v. Löwis added the comment:
> Probably os.execv() should be implemented on Windows with _wexecv()
> instead of _execv(). Likewise for other functions which have "wide"
> versions. Or maybe it wouldn't be worth the effort, since it would
> mean writing separ
Martin v. Löwis added the comment:
> Is this approach of coercing to unicode and only using the wide api
> "blessed"?
It's not. If people use byte strings, they specifically ask for what
they get; Python shouldn't second-guess the data types.
> I certainly think
Martin v. Löwis added the comment:
Apparently, you are using the interactive shell on Microsoft Windows. This will
use the "OEM code page"; which one that is depends on the exact Windows
regional version you are using.
You shouldn't decode the string with
Martin v. Löwis added the comment:
> But why are they not a space?
Because the Unicode standard says they are not. We have a good tradition in
Python to follow standards where they apply, and it appears that the Unicode
standard is crystal clear that the characters in question are *
Martin v. Löwis added the comment:
Can you please regenerate the patch against default's head?
--
___
Python tracker
<http://bugs.python.org/issue1>
___
___
Martin v. Löwis added the comment:
How do you infer the data types for the parameters?
--
___
Python tracker
<http://bugs.python.org/issue13404>
___
___
Pytho
Martin v. Löwis added the comment:
Please don't use git-style diffs then, since otherwise the review can't figure
out what the patch applies to (and neither could I figure that out).
--
___
Python tracker
<http://bugs.python.o
Martin v. Löwis added the comment:
Making it a feature request would procedurally be ok. However, I'd immediately
refuse that as feature creep. Use regular expressions for more advanced
stripping than what the .strip method provides.
--
___
P
Martin v. Löwis added the comment:
LGTM.
--
___
Python tracker
<http://bugs.python.org/issue1>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
> Thus strip and isspace are now unusable methods in Python for common use
> cases.
Please recognize that you haven't demonstrated this at all. U+200B is
*not* a character that is common, not even remotely. It's a rare,
infrequent, unus
Martin v. Löwis added the comment:
> IIUC, it means that the library/application should not use the bytes API if
> it intends to be supported on major platforms.
I think you misunderstand; it does not literally mean that. Instead, it
means that the library/application either must not u
Martin v. Löwis added the comment:
This approach is not correct C. You may pass an "incorrect" number of arguments
only if the function is declared with an ellipsis, else the behavior is
undefined (6.5.5.2p6). Your proposed approach works with most implementations
of C, but Python
Martin v. Löwis added the comment:
FWIW, I think that a PEP will be needed to redesign the module initialization
for Python 4. Hopefully, this time people will then identify all requirements
before the PEP is accepted (which unfortunately didn't happen for PEP
Martin v. Löwis added the comment:
Not sure whether this is actually new, but it may be that Dave Winer is
migrating all this stuff to Amazon S3, and that he just didn't get to restoring
the time service yet.
--
___
Python tracker
Martin v. Löwis added the comment:
Joining the chorus: people who need it in their application will have to add it
themselves (monkeypatching the aliases dictionary as appropriate).
--
nosy: +loewis
___
Python tracker
<http://bugs.python.
Martin v. Löwis added the comment:
I really do propose to close this issue as "won't fix". By the time Python 4
comes along, things will have changed a lot; it's not clear that the value of
keeping it open will outweigh the cos
Martin v. Löwis added the comment:
> What about providing a function that "init" would call to get this
> information, instead of a "hidden" parameter?.
How would the function that init calls itself get the information,
without a hidden parameter?
--
title
Martin v. Löwis added the comment:
Indeed, PEP 8 mandates that constants be written in all uppercase, so changing
it would actually make it deviate from PEP 8. Also, using a lower-case variable
name "string" would be a bad choice because it collides with a module name.
-
Martin v. Löwis added the comment:
If you *really* want to solve this problem, you could start working on making
Python release all memory at interpreter shutdown. Please understand that this
project may well take several years to complete, but it would help not only
your project, but also
Martin v. Löwis added the comment:
> Python interpreter already have that information internally. The
> initial proposal was to pass it to the init as an additional
> parameter. My suggestion is to export it as a new function that the
> init can call if VERSION >=3.3.
Jesus: Ple
Martin v. Löwis added the comment:
> Reverse question: what would be the minus of having this alias?
Please accept that this issue is closed.
--
___
Python tracker
<http://bugs.python.org/issu
Martin v. Löwis added the comment:
Thanks for the report; this is now fixed.
Please use the PyPI bug tracker for such reports in the future, which can be
found by following "Bug reports" on pypi.python.org, to
http://sourceforge.net/tracker/?group_id=66150&atid=513503
---
Martin v. Löwis added the comment:
Please let us know when you consider your patch ready for review.
--
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
The patch looks good to me.
To study Microsoft's malloc, see VC\crt\src\malloc.c. Typically, it uses
HeapAlloc from the CRT heap, unless it's in 32-bit mode, and __active_heap is
either __V6_HEAP or __V5_HEAP. This is determined at startup by __h
Martin v. Löwis added the comment:
> 1) the current approach of having a dict with name -> intvalue doesn't work
> anymore, and a name -> valuelist should be used instead;
> 2) the reverse dict for this would have to use tuples as keys, but I'm not
> s
Martin v. Löwis added the comment:
I think it's besides the point of this patch to ifdef it out. If John wants a
version of Python with this enabled, he can well enough build one without our
permission. So it would be useful only if it was always available, and perhaps
properly integ
Martin v. Löwis added the comment:
> I know that 2.7 patch is not going to be integrated in mainline but would you
> consider reviewing it?
I personally won't. If there are things that will apply to 2.7 as well,
you surely can backport th
Martin v. Löwis added the comment:
There is plenty of time until 3.3. OTOH, if Eric wants to work on it now: you
got a week :-) Do recognize that there is a patch to start from already.
--
___
Python tracker
<http://bugs.python.org/issue5
Martin v. Löwis added the comment:
Closing this as rejected, for the reasons given.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
The only subtlety is that the result is the offset from the beginning,
independent of the how value. It may also raise exceptions.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
Why do you think this is a bug? Is this behavior causing problems?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
> First, I don't understand why we need to check both "foo.so" and
> "foomodule.so".
Because we always did, i.e. changing it now may break backwards compatibility.
Now, as for why we always had *module.so also: it may be th
Martin v. Löwis added the comment:
I would have appreciated had you considered my review before pushing that
change.
--
___
Python tracker
<http://bugs.python.org/issue11
Martin v. Löwis added the comment:
It's reasonable that string % formatting might have become slower...
I wonder what the issue is at this point. Unless you can state a clear issue
that you want to see resolved, I propose to close this report as in
Martin v. Löwis added the comment:
> We should like the IDLE shell to give the same results as the standard shell.
I disagree that this should be an absolute principle. Two standard
shells may not give the same result due to running in different
environments, so forcing IDLE to give the s
Martin v. Löwis added the comment:
> I also so not understand you reverting the title to the arguably incorrect
> non-parallel construction.
That is an (unfortunate) side effect of replying by email.
--
___
Python tracker
<http://bugs.p
Martin v. Löwis added the comment:
> One might say, "ok, this is a bug in distutils/distribute, it should
> explicitly specify UTF-8 encoding when writing egg-info." But if this
> is a sensible thing for distutils/distribute to do, regardless of
> user locale, why w
Martin v. Löwis added the comment:
> PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_GET_SIZE(),
> ... do reallocate a Py_UNICODE* string for a ready string, but I
> don't think that it is a usual use case.
Define "usual". There were certainly plenty of oc
301 - 400 of 4778 matches
Mail list logo
