New submission from Marc Abramowitz:
I just installed Python 3.0a4 from source on an Ubuntu system and noticed that
it doesn't seem to set the distutils.sysconfig config var: SO:
```
vagrant@ubuntu:~/src/Python-3.4.0a4$ python3.4
Python 3.4.0a4 (default, Nov 11 2013, 17:11:59)
[GCC 4.6.3
Marc Abramowitz added the comment:
Thanks Barry, for tracking down that this is intentional.
I wonder how one gets this value in Python code now? For example, the reason I
stumbled upon this in the first place is that there is some code in PyCrypto
(https://github.com/dlitz/pycrypto/blob
Marc-Andre Lemburg added the comment:
Jan, the codec implements an encoding which has certain characteristics just
like any other codec. It works both in Python 2 and 3 without problems.
The documentation is no longer true, though. Ever since we added encoding
markers to source files, the raw
Marc-Andre Lemburg added the comment:
On 11.11.2013 20:21, Serhiy Storchaka wrote:
That's not intended. The normalize() function is supposed to
prepare the locale for the lookup. It's not supposed to be applied
to the looked up value.
Last patch doesn't contain this part of tests
Marc-Andre Lemburg added the comment:
On 10.11.2013 10:20, Nick Coghlan wrote:
The long discussion in issue 7475 and some subsequent discussions I had with
Armin Ronacher have made it clear to me that the key distinction between the
codec systems in Python 2 and Python 3 is the following
Marc-Andre Lemburg added the comment:
On 10.11.2013 14:03, Nick Coghlan wrote:
Updated patch (v5) with a more robust chaining mechanism provided as a
private _PyErr_TrySetFromCause API. This version eliminates the previous
whitelist in favour of checking directly for the ability
Marc-Andre Lemburg added the comment:
On 10.11.2013 15:39, Nick Coghlan wrote:
On 10 November 2013 23:21, Marc-Andre Lemburg rep...@bugs.python.org wrote:
This doesn't look right:
diff -r 1ee45eb6aab9 Include/pyerrors.h
--- a/Include/pyerrors.hSat Nov 09 23:15:52 2013 +0200
Marc-Andre Lemburg added the comment:
On 06.11.2013 16:51, Alexander Belopolsky wrote:
MAL: Have you thought about the rounding/truncation issues
associated with not showing microseconds ?
Sure, otherwise I wouldn't have mentioned it :-)
mxDateTime always uses 2 digit fractions when
Marc-Andre Lemburg added the comment:
On 05.11.2013 21:31, STINNER Victor wrote:
2013/11/5 Alexander Belopolsky rep...@bugs.python.org:
+1 on adding an option to isoformat(). We already have an optional sep
argument, so the symmetry with __str__ is not complete. To make this option
Marc-Andre Lemburg added the comment:
On 04.11.2013 14:30, STINNER Victor wrote:
It would be simpler to just drop these custom codecs (rot13, bz2, hex, etc.)
instead of helping to use them :-)
-1 for the same reasons I keep repeating over and over and over again :-)
The codec system
New submission from Marc Liyanage:
I'm running Python 2.7 in a sandboxed OS X app. There are restrictions on the
naming of POSIX semaphores when running in the sandbox. Specifically, there is
a mandatory prefix.
I would like the ability to inject this prefix into the part
Marc Liyanage added the comment:
leasing - leading
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19478
___
___
Python-bugs-list mailing list
Marc Liyanage added the comment:
I'm thinking something along the lines of
char *env = Py_GETENV(PYTHONSEMAPHOREPREFIX);
if (env *env != '\0') {
PyOS_snprintf(buffer, sizeof(buffer), %s/mp%ld-%d, env,
(long)getpid(), counter++);
} else {
PyOS_snprintf(buffer
Marc Liyanage added the comment:
From the description above, I would guess shared memory names as well, but I
don't know which parts of the Python library use those, if any.
In general, it's easy to adjust the Python code to deal with the restriction of
the sandboxed environment (mostly file
Marc Liyanage added the comment:
Great to hear that this is mostly supported in 3.4. I would definitely like to
see the small change added that lets me insert a string before the leading
slash.
It would also be helpful to have it in Python 2.7 as well
Marc Schlaich added the comment:
Ah that's great. The issue is resolved with SQLite 3.8.1.
However, would be great if a newer SQLite version comes already bundled with
Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Marc Schlaich:
My System:
$ python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import sqlite3
sqlite3.version
'2.6.0'
sqlite3.sqlite_version
'3.6.21'
Test Script
Marc Schlaich added the comment:
Ok, these issues were probably due to the shipped version of PyGTK (which is
used as event scheduler). Since I built my own Python and own PyGTK everything
looks fine.
--
resolution: - invalid
status: open - closed
Marc-Andre Lemburg added the comment:
On 24.10.2013 16:59, Andrei Dorian Duma wrote:
I added a patch (my first patch!).
platform.linux_distribution() now first looks in /etc/os-release. If this
file is not found, checking continues as before.
Looks good
Marc-Andre Lemburg added the comment:
Christian: I think adding MIME types falls under platform support and we do
still add platform support to Python 2.7.
That said, the mimetypes module *does* use platform files for determining MIME
types, so adding missing MIME types there will likely
Marc-Andre Lemburg added the comment:
On 21.10.2013 02:07, Ezio Melotti wrote:
Ezio Melotti added the comment:
Fixed, thanks for the patch!
Thanks, Ezio, for the check-in.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Marc-Andre Lemburg added the comment:
On 19.10.2013 07:06, Martin Matusiak wrote:
Martin Matusiak added the comment:
It seems the versions of IronPython 1.0 mentioned in test cases do actually
support the in keyword, so the first version of the patch is probably
sufficient.
Example
Marc-Andre Lemburg added the comment:
On 19.10.2013 12:11, Martin Matusiak wrote:
Attaching a v3 which uses in and startswith.
Just for good measure I ran this module on IronPython 1.0 and it fails on
import:
- bytes literal: b'(__libc_init)'
- if as infix operator: line 177
Marc-Andre Lemburg added the comment:
On 19.10.2013 13:37, Martin Matusiak wrote:
Martin Matusiak added the comment:
Double checked that the test passes against both default and 2.7 branches.
Is there anything else that needs to happen here or are you satisfied,
Marc-Andre
Marc-Andre Lemburg added the comment:
On 18.10.2013 11:39, Stefan Krah wrote:
Stefan Krah added the comment:
I believe you, but I'd like to understand why. :)
:-)
It seems to me that a module and also PyInit_xxx() can be loaded portably.
Say the handles to the module are cached
Marc-Andre Lemburg added the comment:
On 17.10.2013 21:01, Stefan Krah wrote:
Stefan Krah added the comment:
I've looked at this, and the question is: Do we really need a capsule
API? All relevant symbols in _decimal start with Py* and shouldn't
need to be static.
You need a capsule
Marc-Andre Lemburg added the comment:
The patch looks good, except one nit:
if 'IronPython' in sys_version
is probably not supported in IronPython 2.0, since support for n-char in
m-char tests were added after Python 2.1.
Now, you can either leave this in and remove the IronPython 2.0
Marc-Andre Lemburg added the comment:
On 08.10.2013 10:46, Antoine Pitrou wrote:
utf-16 isn't that widely used, so it's probably fine if it becomes a bit
slower.
It's the default encoding for Unicode text files and APIs on Windows,
so I'd say it *is* widely used :-)
http
Marc-Andre Lemburg added the comment:
On 08.10.2013 11:03, Antoine Pitrou wrote:
utf-16 isn't that widely used, so it's probably fine if it becomes
a bit slower.
It's the default encoding for Unicode text files and APIs on Windows,
so I'd say it *is* widely used :-)
I've never seen any
Marc-Andre Lemburg added the comment:
On 08.10.2013 11:33, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
MS Notepad and MS Office save Unicode text files in UTF-16-LE,
unless you explicitly specify UTF-8, just like many other Windows
applications that support Unicode text files
Marc-Andre Lemburg added the comment:
On 08.10.2013 11:42, Serhiy Storchaka wrote:
UTF-16 codec still fast enough. Let first make it correct and then will try
optimize it. I have an idea how restore 3.3 performance (if it worth, the
code already complicated enough).
That's a good plan
Marc-Andre Lemburg added the comment:
On 08.10.2013 12:30, Antoine Pitrou wrote:
UTF-8, UTF-16 and UTF-32 codecs need to be as fast as possible
in Python to not create performance problems when converting
between platform Unicode data and the internal formats
used in Python.
As fast
Marc Abramowitz added the comment:
Nice to see this moving along as I helped Jesús a while back with some testing
on OS X and FreeBSD. The buildbots in particular sound like a great asset.
Let me know if I can help again with testing, though it looks like the basics
are pretty well-covered
Marc-Andre Lemburg added the comment:
Wouldn't it be possible to use the old version as fallback solution
in case the -c switch approach fails or have a command line option
to pass in the version in order to bypass all of this ?
Stefan: Why don't you propose a patch which implements
Marc-Andre Lemburg added the comment:
On 17.09.2013 11:09, Nick Coghlan wrote:
Nick Coghlan added the comment:
I agree the different audiences problem can be addressed by using
appropriate commit message formatting to say this bit goes in NEWS (perhaps
with some metadata to say which
Marc-Andre Lemburg added the comment:
On 13.09.2013 15:30, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Patch updated. Added tests. The locale_alias mapping updated to be
self-consistency (i.e. for every name in locale_alias.values()
normalize(name) == name).
Could you
Marc-Andre Lemburg added the comment:
On 13.09.2013 16:34, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Could you elaborate on the alias changes ?
Were those coming from an updated X11 local.alias file ?
No, they are not from X11 local.alias file. They are a result
Marc-Andre Lemburg added the comment:
On 13.09.2013 19:24, Terry J. Reedy wrote:
Terry J. Reedy added the comment:
I thought that that was the specification*: the encoding comment should be
the first line unless it has to be the second line to allow for an executable
comment. Executing
Marc-Andre Lemburg added the comment:
On 13.09.2013 22:23, R. David Murray wrote:
R. David Murray added the comment:
Just to be clear: the reason I am opposed is that the audience for Misc/NEWS
is different from the audience for commit messages, and I would prefer that
the text reflect
Marc-Andre Lemburg added the comment:
On 13.09.2013 22:51, Brett Cannon wrote:
Brett Cannon added the comment:
I would argue, MAL, that what you want Misc/NEWS to be should instead be
merged into the end of What's New. If something changed which could
potentially break a user it should
Marc Schlaich added the comment:
Yes, I could reproduce segfaults on Python 2.7 (looks like it is even worse
than on 2.6 where it appeared only randomly).
I was not quite accurate in my initial comment. I don't use any custom C
extensions but I'm using pygtk/gobject so it might be a bug
Marc Schlaich added the comment:
The generator.patch from #14432 didn't help. The other couldn't be applied to
2.7.
I have a core dump, should I upload it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18683
Marc-Andre Lemburg added the comment:
You should be able to squeeze out some extra cycles by
avoiding the bit calculations using a simple range check
for ch = 0xd800:
+# if STRINGLIB_MAX_CHAR = 0xd800
+if (((ch1 ^ 0xd800)
+ (ch1 ^ 0xd800)
+ (ch1
Marc-Andre Lemburg added the comment:
On 02.09.2013 18:56, Serhiy Storchaka wrote:
Oh, I were blind. Thank you Marc-Andre. Here is corrected patch.
Unfortunately it 1.4-1.5 times slower on UTF-16 encoding UCS2 strings than
previous wrong patch.
I think it would be faster to do
Marc-Andre Lemburg added the comment:
.__repr__() is not really allowed to return Unicode objects in Python 2.x. If
you do this, you're on your own. The CPython internals try to convert any
non-str object to a str object, but this is only done to assure that
PyObject_Repr() always returns
Marc-Andre Lemburg added the comment:
Serhiy Storchaka wrote:
.__repr__() is not really allowed to return Unicode objects in Python 2.x.
If you do this, you're on your own.
PyObject_Repr() contains a code which converts unicode to str and raise an
exception if __repr__() result
New submission from Marc Schlaich:
I'm running unittests on a CentOS 6.4 Virtual Box slave via Jenkins on a
Windows host. Randomly I get core dumps for no obvious reason. I don't
use any C extension in my code and don't use ctypes. The (proprietary)
software is plain Python with a multi
Marc-Andre Lemburg added the comment:
On 03.08.2013 00:47, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
Does a result of one and one half seconds make sense as the result of a
floor division operation?
Yes. Timedeltas behave as integers containing the number
Marc-Andre Lemburg added the comment:
On 02.08.2013 16:37, R. David Murray wrote:
I got the impression from what I read that -e included additional control
sequences, but perhaps I misunderstood and that only meant that the data
stream was expected to *use* additional control sequences
Marc-Andre Lemburg added the comment:
On 03.08.2013 18:32, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
What is so special about seconds? Why not days? As in
timedelta(3) // 2
timedelta(1)
Note that in 3.x we have timedelta over timedelta division that lets
Marc-Andre Lemburg added the comment:
The alias was added by Hye-Shik Chang:
http://hg.python.org/cpython-fullhistory/annotate/887ce39f95f2/Lib/encodings/aliases.py#198
I've added him to the nosy list.
If the alias don't match, we'd have to add a codec for the mismatching encoding
Marc-Andre Lemburg added the comment:
Here's a usable reference:
http://www.w3.org/TR/html4/struct/dirlang.html#bidi88598
+1 on adding the alias.
Also see
http://lists.gnu.org/archive/html/lynx-dev/2012-02/msg00041.html
for how Lynx does this.
The URL also mentions iso-8859-8-e, which
Marc-Andre Lemburg added the comment:
Madison May wrote:
This issue may have been dead for 3+ years, but perhaps it's time its brought
back to the surface. Aside from simple being convenient for general security
practices, a stdlib module for crypto routines would enable python to handle
Marc-Andre Lemburg added the comment:
1. Added an intro paragraph that makes it clear this is a living document,
not set and forget.
If we want to make this a living document, I think the PEP will
have to receive its own internal version number and a history
section at the end explaining
Marc Abramowitz added the comment:
I agree also that io is a good place for the basic version that doesn't do file
descriptor stuff and maybe the fancy file descriptor stuff should be a separate
issue and should go in subprocess.
To move this along and generate more discussion, I took code
Marc Abramowitz added the comment:
Oops, Nick = Brett.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15805
___
___
Python-bugs-list mailing
Marc Abramowitz added the comment:
Thanks Nick! I'll work on applying your suggestions a little later. And I'll
add a note about it not working with subprocesses because I realized that I
forgot to do that.
Regarding redirect_stdfile, which is presumably what you meant by name-based
API, I
Marc Abramowitz added the comment:
I like Nick's version. I don't know if __exit__ really needs error checking,
but I like the API. For me, it strikes a good balance between being intuitive
and being general enough to do all the stuff I'd like to do.
Should the docstrings mention
Changes by Marc Abramowitz msabr...@gmail.com:
--
nosy: +Marc.Abramowitz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15805
___
___
Python-bugs
Marc Abramowitz added the comment:
As it happens, I wrote a similar context manager to Victor's recently for a
setup.py because I wanted to suppress compiler errors that are output to the
console by distutils.ccompiler.CCompiler.has_function. As Victor mentioned, for
this to work
Marc-Andre Lemburg added the comment:
It may be useful to also add the start position of the grapheme to the iterator
output.
Related to this, please also see this pre-PEP I once wrote for a Unicode
indexing module:
http://mail.python.org/pipermail/python-dev/2001-July/015938.html
Marc-Andre Lemburg added the comment:
On 07.07.2013 11:11, Ronald Oussoren wrote:
The easiest solution to avoid this deprecated API is therefore to drop the
_gestalt extension and remove its use in platform.mac_ver()
I think it should only be removed in case we no longer support
Mac OS X
Marc-Andre Lemburg added the comment:
On 07.07.2013 16:31, Alex Henderson wrote:
Having discussed this with Ezio, I think the better option might be to raise
ValueError instead - if someone is expecting to be able to silently recover
from errors they won't be able to, and should find out
Marc-Andre Lemburg added the comment:
On 08.07.2013 13:55, Ronald Oussoren wrote:
Do we follow the deprecation procedure for private functions as well?
The patch removes a private and undocumented extension, and removes a private
function that uses that extension. There is no change
Marc-Andre Lemburg added the comment:
On 06.07.2013 18:17, Ronald Oussoren wrote:
As to the question of actually signing the installer: we ask the PSF about
acquiring a developer account once we have something that can actually be
signed.
Please write to p...@python.org with an explanation
Marc-Andre Lemburg added the comment:
On 08.07.2013 14:08, Ronald Oussoren wrote:
Ronald Oussoren added the comment:
I had hoped to just drop it in 3.4.
To remove:
* extension _gestalt
* function platform._mac_ver_gestalt
* function platform._mac_ver_lookup (only used
Marc-Andre Lemburg added the comment:
On 27.06.2013 09:36, STINNER Victor wrote:
STINNER Victor added the comment:
Extract of GNU standards:
# make distclean
# Delete all files from the current directory that are created by
# configuring or building the program. If you have
Marc-Andre Lemburg added the comment:
On 23.06.2013 22:43, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
unicodedata.name() was discussed in #12353 (msg144739) where MvL argued that
misspelled names are better than corrected because they are more likely to
appear
Marc-Andre Lemburg added the comment:
On 24.06.2013 00:00, Jeffrey Armstrong wrote:
Jeffrey Armstrong added the comment:
...the fact that this issue has been open for almost 2 years is quite
ridiculous.
I thought that I'd add a little statistic for everyone that might put this
bug
Marc-Andre Lemburg added the comment:
On 24.06.2013 00:52, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
There has been a relatively recent discussion of case mappings under #12753
(msg144836).
I personally agree with Martin: str.upper/lower should remain the way
Marc-Andre Lemburg added the comment:
On 24.06.2013 10:05, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Perhaps unicodedata.aliases() should return not a list, but an ordered dict.
What name should use the namereplace error handler? Original or corrected?
Should it use
Marc-Andre Lemburg added the comment:
On 24.06.2013 16:35, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
MAL Please leave the function as it is, i.e. a 1-1 mapping to the
MAL official, non-changing Unicode name reference (including
MAL spelling errors, etc). Same
Marc-Andre Lemburg added the comment:
On 24.06.2013 16:58, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
Here is an example of prior art that is relevant to this discussion:
charnames::viacode(code)
..
As mentioned above under ALIASES, Unicode 6.1 defines extra
Marc-Andre Lemburg added the comment:
On 24.06.2013 18:10, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
The .aliases() function would have to return a list, not a single
name, so a parameter would cause the return type to change, which
is not a good idea.
You
Marc-Andre Lemburg added the comment:
I agree with Martin.
At the time Unicode was added to Python, there was no single Unicode property
for white space, so I had to deduce this from the other available properties.
Now that we have a white space property in Unicode, we should start using
Marc-Andre Lemburg added the comment:
On 14.06.2013 03:43, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
PEP 393 implementation has already added the fast path to decimal encoding:
http://hg.python.org/cpython/diff/8beaa9a37387/Objects/unicodeobject.c#l1.3735
Marc-Andre Lemburg added the comment:
On 12.06.2013 07:32, Alexander Belopolsky wrote:
Alexander Belopolsky added the comment:
It looks like we a approaching consensus on some points:
1. Mixed script numerals should be disallowed.
2. '\N{MINUS SIGN}' should be accepted
Marc-Andre Lemburg added the comment:
[In the light of the current discussion on python-ideas regarding adding
support for the Unicode minus sign]
I'm +1 on adding support for the minus code point, since
it's the correct correspondent to the plus code point in Unicode.
The traditional ASCII
Marc-Andre Lemburg added the comment:
I've changed my mind :-)
Restricting the decimal encoder to only accept code points from one of the
possible decimal digit ranges is a good idea. Let's do that.
--
___
Python tracker rep...@bugs.python.org
http
New submission from Marc:
Using TkInter as gui, running a module that worked in 3.0 (I believe).
It is trying to print a warning message about
RuntimeWarning: overflow encountered in double_scalars
and stops my process (running eval) returning this error
File C:\Python32\lib\idlelib
Marc-Andre Lemburg added the comment:
Not a bad idea. More information is always better when it comes to
documentation :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17844
New submission from Marc Brünink:
The documentation for is not very clear regarding the usage of CDLL and PyDLL.
Especially it is not obvious that you should use PyDLL whenever you call any
function of the Python/C API. Since calling a Python/C API function without
owning the GIL will most
Marc-Andre Lemburg added the comment:
SSL certificate hostname matching is defined in RFC 2818:
* http://www.ietf.org/rfc/rfc2818.txt
It's not very verbose on how exactly matching should be done:
Names may contain the wildcard
character * which is considered to match any single domain
Marc-Andre Lemburg added the comment:
Here's another long discussions about SSL hostname matching that may provide
some useful insights:
* https://bugzilla.mozilla.org/show_bug.cgi?id=159483
Note how RFC 2595 doesn't even allow sub-string matching. It only allows '*' to
be used as component
Marc-Andre Lemburg added the comment:
On 17.05.2013 13:11, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Ubuntu 32-bit, gcc 4.6.3. The bug requires 64 bit.
This patch should fix it.
int and long are the same size on Linux 64-bit platforms.
You probably want to use short
Marc-Andre Lemburg added the comment:
On 17.05.2013 13:42, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg added the comment:
On 17.05.2013 13:11, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Ubuntu 32-bit, gcc 4.6.3. The bug requires 64 bit.
This patch should fix
Marc-Andre Lemburg added the comment:
On 15.05.2013 01:28, Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc added the comment:
The official way to build without unicode is
./configure --enable-unicode=no
But see issue17979.
The official way to build without Unicode is:
./configure
Marc-Andre Lemburg added the comment:
Please note that the official way to build Python without Unicode
support is (see http://bugs.python.org/issue445762):
./configure --disable-unicode
See http://bugs.python.org/issue8767 for the most recent set of fixes
that were supplied to make it work
Marc-Andre Lemburg added the comment:
On 02.05.2013 01:59, Dmi Baranov wrote:
Dmi Baranov added the comment:
I think its not possible while codecs registry contains search callbacks
(stateless-registry)
It is possible: we'd just need to invent a way to ask search functions
for the list
Marc-Andre Lemburg added the comment:
On 02.05.2013 16:41, Nick Coghlan wrote:
Nick Coghlan added the comment:
This is actually similar to the problem with getting the list of modules an
importer provides (that is, we don't currently have an officially defined
method in the importer
Marc-Andre Lemburg added the comment:
On 02.05.2013 16:45, Walter Dörwald wrote:
...
The search function can't return a list of codec names in this case, as the
list is infinite.
True.
The search object will have to be allowed to raise a
NotImplementedError or some other error/return value
Marc-Andre Lemburg added the comment:
On 02.05.2013 16:53, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg added the comment:
On 02.05.2013 16:45, Walter Dörwald wrote:
...
The search function can't return a list of codec names in this case, as the
list is infinite.
True.
The search
Marc-Andre Lemburg added the comment:
Thanks, Serhiy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17857
___
___
Python-bugs-list mailing list
Marc-Andre Lemburg added the comment:
On 28.04.2013 05:20, Ned Deily wrote:
Ned Deily added the comment:
Marc-Andre, can you elaborate on why you think Python 3 is not affected? The
changes for Issue17073 also added sqlite3_int64 to 3.2, 3.3, and default and,
for me on 10.4, _sqlite3
New submission from Marc-Andre Lemburg:
This is essentially the same issue as http://bugs.python.org/issue14572.
The following addition in Python 2.7.4 (compared to 2.7.3) reintroduced the
same problem in a different place:
--- Python-2.7.3/Modules/_sqlite/util.h 2012-04-10 01:07:33.0
Marc-Andre Lemburg added the comment:
Adding the same people to the nosy list as on issue #14572.
--
nosy: +Joakim.Sernbrant, Marc.Abramowitz, dmalcolm, ned.deily, petri.lehtinen,
python-dev
type: - compile error
___
Python tracker rep
Changes by Marc-Andre Lemburg m...@egenix.com:
--
title: sqlite modules doesn't build on 2.7.4 with Mac OS X 10.4 - sqlite
modules doesn't build with 2.7.4 on Mac OS X 10.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17857
Marc-Andre Lemburg added the comment:
On 27.04.2013 22:27, Serhiy Storchaka wrote:
Serhiy Storchaka added the comment:
Here is a patch for 2.7. Please test. Should it be fixed on 3.x?
Thanks, Serhiy.
I can confirm that the patch fixes the problem with 2.7.4 on
Mac OS X (and probably
Marc-Andre Lemburg added the comment:
On 25.04.2013 10:14, Nick Coghlan wrote:
Nick Coghlan added the comment:
A more consistent alternative conversion:
encode(base64) = codecs.encode(..., base64_codec)
encode(rot13) = codecs.encode(..., rot_13)
encode(zlib
Marc-Andre Lemburg added the comment:
Just copying some details here about codecs.encode() and
codec.decode() from python-dev:
Just as reminder: we have the general purpose
encode()/decode() functions in the codecs module:
import codecs
r13 = codecs.encode('hello world', 'rot-13
801 - 900 of 2192 matches
Mail list logo
