Martin v. Löwis added the comment:
> (1) Upon string creation, do we want to *promise* to discard the UTF-8 and
> wstr, so that the caller can memory manage?
I don't understand the question. Assuming "discards" means "releases"
here, then there is no API which
Martin v. Löwis added the comment:
maniram: the proper course is to publish such a module on PyPI. Then, if there
is enough interest in it (after a few years), propose addition to the standard
library.
--
nosy: +loewis
___
Python tracker
<h
Martin v. Löwis added the comment:
> Why is the utf-8 representation not cached when it is generated for
> ParseTuple et alia?
It is.
> When a string is created from a wchar_t array, who is responsible for
> releasing the original wchar_t array?
The caller.
> As I read
Martin v. Löwis added the comment:
Code added to the standard library should be contributed by its author, with an
explicit statement of plans to support it in an ongoing manner, and preferably
also with plans to stop providing standalone releases over time.
--
nosy: +loewis
Martin v. Löwis added the comment:
I agree with Antoine: a single test testing that we actually raise exceptions
properly should be sufficient.
OTOH, the patch doesn't hurt (AFAICT), so I wouldn't mind if it was applied
as-is.
--
Martin v. Löwis added the comment:
> "If you have to work with XML, ElementTree is usually the best
> choice, because it has a simple API and it's efficient [or whatever].
I still object such a wording, for many reasons.
--
__
Martin v. Löwis added the comment:
Thanks, this is a known issue. I'm not too worried, since they are fairly
artificial. In the cases I've looked at, I don't think anything can be done
about that.
--
nosy: +loewis
___
Python
Martin v. Löwis added the comment:
Can you please provide your exact testing procedure? Standard iobench.py
doesn't support testing for separate ASCII, UCS-1 and UCS-2 data, so you must
have used some other tool. Exact code, command line parameters, hardware
description and timing re
Martin v. Löwis added the comment:
> Oooh, it's just faster because encoding ASCII to UTF-8 is now O(1)
It's actually still O(n): the UTF-8 data still need to be copied into a
bytes object.
--
___
Python tracker
<http://bugs.pytho
Martin v. Löwis added the comment:
Is there a reason not to renumber token.h?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13629>
___
___
Martin v. Löwis added the comment:
This is correct behavior. \x00 is not supported in XML: not in raw form, and
not in escaped form. To transmit binary data in XML, use base64.
--
nosy: +loewis
status: open -> closed
___
Python tracker
&l
Martin v. Löwis added the comment:
I'd rather have you maintain poodle.python.org instead of maintaining Python
translations off-site.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
naoki: what is your actual complaint about the installation being outdated? Are
you referring to the message catalog (documentation version), or the software?
As for the message catalog, I don't think it should be updated too often (only
once per P
Martin v. Löwis added the comment:
saurik: can you propose a patch?
--
___
Python tracker
<http://bugs.python.org/issue2481>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
I disagree with that approach, basically because I disagree that we need a C
implementation of MT. Platforms that don't provide /dev/urandom will just have
to be less secure. Using the current time (in milliseconds if available) plus
the current pid
Martin v. Löwis added the comment:
Removing the if condition would be incorrect. The maximum char is computed at
the beginning of the formatting. If, during formatting, need for a padding
character is determined, the padding character must not be larger than the
maximum char of the target
Martin v. Löwis added the comment:
-1. The hash has nothing to do with the lifetime, but with the value of an
object.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
> Martin, I do not understand. The default hash is based on id (as is
> default equality comparison), not value.
In the default implementation, the id *is* the object's value (i.e.
objects, by default, only compare equal if they are identical). So
Martin v. Löwis added the comment:
See http://www.gnu.org/software/autoconf/manual/autoconf.html
for a description of the includedir and libdir options:
— Variable: includedir
The directory for installing C header files.
— Variable: libdir
The directory for installing object code libraries
Martin v. Löwis added the comment:
I haven't read much of this issue, but I strongly dislike the use of named
tuples. Either we want people to use named fields, then we should use a regular
class (possibly with slots), or we want to define the result as two values,
then there should
Martin v. Löwis added the comment:
I suggest to remove all mentionings of 2.3 compatibility from the file (I
actually could find only a single one), for 3.3. Changing 3.2 is out of scope,
as it isn't a bug fix (except that the one place referring to 2.3 claims that
there is a comment a
Martin v. Löwis added the comment:
Zitat von Antoine Pitrou :
> Antoine Pitrou added the comment:
>
> The point of named tuples here is that you can use both
> get_terminal_size().columns
> or
> columns, rows = get_terminal_size()
> depending on the situation.
An
Martin v. Löwis added the comment:
No, I only read the original message. I find it too tedious to read the entire
set of messages just to find out what the issue may be. If an issue has
sufficiently deviated from the original report, it is better closed, and a new
issue is opened.
Even
Martin v. Löwis added the comment:
Paul, can you please elaborate on the patch? The original code looks better to
me than the new code. Why do you think this change is right?
--
___
Python tracker
<http://bugs.python.org/issue13
Martin v. Löwis added the comment:
Please consider this: the code that is there was specifically added by somebody
porting Python to OS/2. So if it doesn't work for you, either OS/2 has changed
(which I don't think is the case), or you are doing something wrong (such as
using the
Martin v. Löwis added the comment:
I disagree that this is a security issue, or an issue at all. All source code
of the site is in a public subversion repository, available for review to any
attacker (as well as any security review) - and that is deliberately so because
we fundamentally
Changes by Martin v. Löwis :
--
versions: -Python 2.6
___
Python tracker
<http://bugs.python.org/issue13769>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
I fail to see the bug. The output is correct, you are just misinterpreting it.
It gives you the error code, error message, and original filename. It doesn't
*actually* claim that the access to test is denied.
Now, changing the file in the message t
Martin v. Löwis added the comment:
In order to arrive at some resolution of this issue, I'm answering the original
question ("Should Python enable a way for folks to inform the OS of
MADV_MERGEABLE memory?"). The discussion has shown that the answer is "no";
the
Martin v. Löwis added the comment:
I recommend to revert this change. It seems that some users are opposed to any
kind of folding (as my earlier folding experiment has demonstrated); users who
*really* don't want to see the history would need to step forward and request a
per-user opti
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg137107
___
Python tracker
<http://bugs.python.org/issue8583>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
I'm +0 on changing 2.6. Many people use setuptools or distribute, so the impact
of this change was higher if those were modified instead of modifying 2.6 - in
particular since few people are expected to pick up these security releases,
a
Martin v. Löwis added the comment:
If users use a browser to do secure uploading, there is no need to publish the
certificate. It is signed by a trusted CA (cacert), so you just need to make
sure your browser knows about the cacert certificate
Martin v. Löwis added the comment:
I suggest that rather than using composite time stamps, decimal.Decimal is used
to represent high-precision time in Python.
On input to os.utime, the function could just polymorphically accept Decimal,
and try its best.
I see three approaches that preserve
Martin v. Löwis added the comment:
Am 03.06.2011 22:11, schrieb Arfrever Frehtes Taifersar Arahesis:
>
> Arfrever Frehtes Taifersar Arahesis added the
> comment:
>
> os.utimensat() and os.futimens() already exist since Python 3.3 and require
> 2-tuples (or None) a
Martin v. Löwis added the comment:
> I support this idea in theory, but as long as decimal is implemented
> in Python, os module should probably expose a low level (tuple-based?)
> interface and a higher level module would provide Decimal-based
> high-precision time.
Can you exp
Martin v. Löwis added the comment:
> One reason is the desire to avoid loading Python module from a
> C-module.
This desire is indeed no guidance for Python development; the opposite
is the case. The only exception may be bootstrapping issues, which I
claim are irrelevant in thi
Martin v. Löwis added the comment:
> I can fill separate bug for packaging, server certificate validation
> and support for non-SSL builds of python (for which there is
> workaround with upload -r option that I've just discovered),
> but it is an additional delay and the only
Martin v. Löwis added the comment:
I don't think the name should be changed. If anything should be done, we should
reconsider whether this flag is actually needed, or whether some other approach
to selecting a compiler can be taken.
--
___
P
Martin v. Löwis added the comment:
I'm rejecting this patch - it's not the right approach to this problem.
If we want to support VS 2010 project files in some form, we should generate
them out of the VS 2008 files, similar to the vs9to8 script. The conversion
result should definite
Martin v. Löwis added the comment:
> I would like to change the version number calculation to something
> like:
>
> '9.x.y.zzz'
>
> where
>
> 9 is a prefix to get 3.3+ ast.__version__ values to sort higher than
> earlier versions x.y is the Python ve
Martin v. Löwis added the comment:
> Can you elaborate on this?
Not on the tracker; this is appropriate on python-dev.
--
___
Python tracker
<http://bugs.python.org/issu
Martin v. Löwis added the comment:
I lost track what problem precisely this patch solves, so it's hard to tell
whether it's a bug fix or not.
--
___
Python tracker
<http://bugs.python.
Martin v. Löwis added the comment:
I suggest to change sys.platform to 'linux' in future releases (3.3). For
bugfix releases (2.7, 3.2), I'd keep it as 'linux2' even on Linux 3. For
security-only releases (2.6, 3.1),
Martin v. Löwis added the comment:
> This change is reasonable for the long term. But it *will* break a lot of
> code.
[If you favor a specific change, please indicate what that is. I'm
assuming you support my proposal for the moment :-]
I agree it will break a lot of code, bu
Martin v. Löwis added the comment:
Actually, on Windows, PYTHON is typically not set at all. So the likelihood of
it being set to Python 3 is very low, unless you are trying to build Python
documentation from time to time.
Sye: I fail to see the point of your patch. sphinx-build.py already
Martin v. Löwis added the comment:
> The change to sys.platform=='linux' would break code even on current
> platforms.
Correct. Compared to introducing 'linux3', I consider this the better
change - it likely breaks earlier (i.e. when porting to Python 3.3).
&g
Martin v. Löwis added the comment:
> I can adapt os_getcwd_buffer-2.patch to support Solaris/OpenBSD, but
> do we need a dynamic buffer? (do we need to support OS without
> PATH_MAX)
>From a practicality point of view, we need to make no change at all:
nobody sane ever has a cur
Changes by Martin v. Löwis :
--
keywords: +patch
Added file: http://bugs.python.org/file22408/8b9da1557ad2.diff
___
Python tracker
<http://bugs.python.org/issue11
Martin v. Löwis added the comment:
So people who say sys.platform shouldn't be used: what do you propose to do
with Lib/plat-linux2 (or, more generally, Lib/plat-*)?
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
What's the point of disallowing the replace error handler? That's a slightly
incompatible change, isn't it?
--
___
Python tracker
<http://bugs.pyt
Martin v. Löwis added the comment:
> Oh, I forgot to give a little bit more details.
>
> b'abc\xff-'.decode('punycode', 'ignore') and
> b'abc\xff-'.decode('punycode', 'replace') raise a UnicodeDecodeError:
> the error h
Martin v. Löwis added the comment:
> What are these directories?
Look and see for yourself.
> Are they still used?
Sure. If you do "import DLFCN", it will come from that directory.
--
___
Python tracker
<http://bugs.py
Martin v. Löwis added the comment:
> Hey, why nobody proposed datetime.datetime objects?
datetime.datetime is extremely bad at representing time stamps.
Don't use broken-down time if you can avoid it.
> By the way, Windows does also use timestamps with a nanosecond
> resolu
Martin v. Löwis added the comment:
> I didn't know that datetime is "extremely bad at representing time
> stamps", could you explain please?
- there is no easy way to convert it into "seconds since the epoch"
- any broken-down time has issues of time stamp orde
Martin v. Löwis added the comment:
How do the two patches relate?
--
___
Python tracker
<http://bugs.python.org/issue9642>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
>> any broken-down time has issues of time stamp ordering in the
>> duplicate hour of switching from DST to normal time
>
> I understand that it is an issue of the datetime module. Can it be
> solved, or is there a design issue in
Martin v. Löwis added the comment:
This looks fine, except for the Tk changes, which should not be made.
--
___
Python tracker
<http://bugs.python.org/issue12
Martin v. Löwis added the comment:
I'd add them to msierror, with no inclusion of the file name.
If you want the file name in the exception, you should uniformly apply this to
all errors in OpenDatabase, and then subclass MSIError to, say, MSIOpenError
which includes a .filename attr
Martin v. Löwis added the comment:
For composite objects, getsizeof should only return the memory of the object
itself, and not that of other objects it refers to. "the object itself"
definitely includes the struct of the object, and also definitely includes
non-PyObject block
Martin v. Löwis added the comment:
> I can't speak, as I've never used those. But can't those directories
> be renamed to Lib/plat-?
That would be incorrect for some systems. For example, FreeBSD does
change sets of symbolic constants across system releases (mostly
add
Martin v. Löwis added the comment:
> BTW I made those Tcl/Tk changes because the instructions point to
> getting the files from the svn repository (using svn export), and
> they unpack into directories with a hyphen before the "8".
Yes, that's unfortunate. These inst
Martin v. Löwis added the comment:
> Martin: PEP 11 lists platforms no-longer supported, but does not list
> those that are.
You mean, "doesn't list the platforms that are still supported"?
That's on purpose: the point of PEP 11 is to warn current users about
forthco
Martin v. Löwis added the comment:
>> That would be incorrect for some systems. For example, FreeBSD does
>> change sets of symbolic constants across system releases (mostly
>> additions, but sometimes also removals). Back then, SunOS 4 and SunOS
>> 5 were comp
Martin v. Löwis added the comment:
It's difficult to tell whether it's the same thing. Is the po file in question
available readily for inspection?
--
___
Python tracker
<http://bugs.python.org
Martin v. Löwis added the comment:
Ok. This is a different issue, then.
--
___
Python tracker
<http://bugs.python.org/issue1475523>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
This is deliberate, and will not be changed (at least not until Python 4, and
likely not even then). Please ask on a Python forum about history and
motivation of the boolean type in Python if you want to know more.
--
nosy: +loewis
status: pending
Martin v. Löwis added the comment:
In any case, mirrors *do* mirror the checksums.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue12
Martin v. Löwis added the comment:
Jim, the question remains why it fails to compile then. If the type is defined,
why does it give an error message "but has not been defined as a type"???
--
___
Python tracker
<http://bugs.python.
Martin v. Löwis added the comment:
Why is the __W macro needed?
Please don't call it WCHAR:
- it conflicts with a same-named macro on Windows
- you are applying it to strings, not characters
FWIW, the compiler doesn't conform to standard C if it rejects this code.
6.4.5p4 says
Martin v. Löwis added the comment:
That's a patch to HP-UX, right? Not one to Python.
--
___
Python tracker
<http://bugs.python.org/issue5999>
___
___
Pytho
Martin v. Löwis added the comment:
Please don't manage independent bugs in a single issue, even if they are
related. The way this is done here will it make hard to track what exactly has
been done, and what needs to be done.
As it stands, please combine all patches into a single one, a
Martin v. Löwis added the comment:
FWIW, it only happens with IDLE; python.exe seems to terminate fine when done.
--
___
Python tracker
<http://bugs.python.org/issue12
Martin v. Löwis added the comment:
In the #2382 code, how is the Windows case supposed to work? Also, what about
systems that don't have wcswidth? IOW, the patch appears to be incorrect.
I like the #6755 approach better, except that it shouldn't be using hard-coded
tables, b
Martin v. Löwis added the comment:
Terry, please don't overreact. Nobody has noticed it during the *long* rc
period of 3.2.1, so it can't be that bad. Actually, I *did* notice, but didn't
have the time to submit a bug report.
--
priority: c
Martin v. Löwis added the comment:
> sys.version_info and sys._mercurial provide all the info needed for someone
> (like me for mnfy)
Can you please elaborate? How do you know from looking at
sys._mercurial whether you can support that AST version?
sys._mercurial changes with every
Martin v. Löwis added the comment:
> I'm still in favor of keeping sys.platform == 'linux3', and you?
Still -1. It should be renamed to 'linux' in future releases, and
back-patched to 'linux2' for maintenance releases.
As for releases that are already out
Martin v. Löwis added the comment:
I give up. Call it 'linux3', then.
--
___
Python tracker
<http://bugs.python.org/issue12326>
___
___
Python-bugs-l
Martin v. Löwis added the comment:
The "Accepted" Resolution was copied from SF. I recall seeing documentation on
SF for the resolutions, but can't find that anymore.
I also recall that on SF, the "accepted" resolution was used to indicate that a
patch was accep
Martin v. Löwis added the comment:
Would you just remove the "XXX" string, or the entire comment? "XXX" is
typically used to indicate that something needs to be done, and the comment
makes a clear statement as to what it is that needs to be done.
Martin v. Löwis added the comment:
A PEP 393 draft implementation is available at
https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into 3.3,
this issue will be outdated: there won't be "narrow" builds of Python anymore
(nor will there b
Martin v. Löwis added the comment:
Python's casemapping functions are not at all untrustworthy or unreliable. They
are entirely deterministic - just limited to the BMP in some builds (in a way
that has already been discussed). Changing the title of the issue.
--
title: Pyt
Martin v. Löwis added the comment:
Notice that Python 2.5 is not supported for bug fixes anymore, so if you truly
believe that there is a bug in Python that needs to be fixed, it would be
better if you could reproduce it in 2.7.
That said, the kind of information you provided really does
Martin v. Löwis added the comment:
> Also what about 3.2? Are you saying that we should fix the bug in
> 3.2/3.3 only and leave 2.x alone or that you don't want the bug to be
> fixed in all the bug-fix releases (i.e. 2.7/3.2)?
Notice that the macros themselves don't fix a
Martin v. Löwis added the comment:
> The point is precisely that we don't change anything: applications
> checking against sys.platform are already broken, there's no reason to
> comfort them into using this defective check.
You grossly misunderstand the concept of "
Martin v. Löwis added the comment:
> I don't understand why do you want to have a special case for Linux.
> sys.platform is already different for each major version of:
That's because Linux uses major version numbers in an entirely different
way than these systems. There
Martin v. Löwis added the comment:
> It means someone upgrading from 2.6 to 2.7 will see sys.platform change
> from "linux3" to "linux2". That breaks compatibility.
No, it doesn't. Code that works on 2.6 and Linux 3 will likely support
both linux2 and linux3, s
Martin v. Löwis added the comment:
> - "linux3" on Python <= 2.7.2 or Python <= 3.2.1
> - "linux2" on 2.7.3 <= Python or 3.2.2 <= Python < 3.3
> - "linux" on Python >= 3.3
>
> I don't see how it will help backward or forward
Martin v. Löwis added the comment:
> Then, let's just advise that all code follow the same path and use
> sys.platform.startswith() (which is really not a difficult change to
> make).
Antoine, please accept that people want better backwards compatibility
than just recommen
Martin v. Löwis added the comment:
> You just said that "we" already had the same problem when Linux 2 was
> released. So hopefully "people want better backwards compatibility"
> would have learnt from that experience, and stopped hard-coding version
> numbers
Martin v. Löwis added the comment:
>>> Really, it's not difficult to understand that code testing for "linux2"
>>> will stop working when "linux3" gets released.
>>
>> This doesn't matter. People will still complain. And, as there is a
Martin v. Löwis added the comment:
> Martin, should we convert all the "accepted" to "fixed" before removing it?
That's not strictly necessary. It would only be retired (roundup does
not support true removal), and as such would then still show up in
issues that cu
Martin v. Löwis added the comment:
>> The only way I can read this argument that makes any sense to me is
>> that you are arguing for a precise build-time OS string. If it is
>> supposed to be an argument in favor of keeping 'linux3' it makes no
>> sense, sinc
Martin v. Löwis added the comment:
Can you please elaborate why we need it?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue12794>
___
___
Pytho
Martin v. Löwis added the comment:
I think this change should be much much smaller in scope. It was (nearly)
agreed to drop the major version if the system is Linux. There is no consensus
(that I'm aware of) to drop the major OS version for all systems.
So I would propose to do this
Martin v. Löwis added the comment:
> So what about doing the same for FreeBSD, SunOS, and Windows?
I agree that's definitely out of scope of this issue.
> If we're changing "linux2" / "linux3" to just "linux", we should be
> consistent and d
Martin v. Löwis added the comment:
For the record, the speed improvement in 2.7 likely results from 79276316b94b.
GC used to be quadratic with the number of objects, and is now only linear.
--
___
Python tracker
<http://bugs.python.org/issue12
Martin v. Löwis added the comment:
>> I agree that's definitely out of scope of this issue.
>
> We could change the title of the ticket :-)
Please keep the issue closed... The issue at hand was that Linux 3
is released, and broke several applications. This issue has been
r
Martin v. Löwis added the comment:
> Well, it is important to somehow get the build information for
> Python, since that tells us which OS features were available
> at the time of compilation.
No, it doesn't (except for a bug that Matthias Klose pointed out).
The OS kernel versi
Martin v. Löwis added the comment:
>> No, it doesn't (except for a bug that Matthias Klose pointed out).
>> The OS kernel version should have *zero* impact on the resulting Python
>> binary. What matters it the C compiler and the version of the C library.
>> The
401 - 500 of 4778 matches
Mail list logo
