Alexander Belopolsky wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. I have opened an issue at
http://bugs.python.org/issue10434 to address this. My vote is to
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg m...@egenix.com wrote:
..
One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
obscure and given that we already have PyUnicode_Concat(), I think
it should be made private and eventually dropped
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg m...@egenix.com wrote:
..
Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
to be available as callable in order to applications or extensions
to use it (without recompile
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg m...@egenix.com wrote:
..
Note that we can have both a macro and a function
version. This is fairly standard practice in Python C-API.
Sure, but what for ?
Mostly just for consistency with the other macros
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg m...@egenix.com wrote:
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg m...@egenix.com wrote:
..
Now, we can't use a macro for [PyUnicode_GetMax()], since the information
has
Hirokazu Yamamoto wrote:
Hello. I found several codes using PyMem_Free to free
allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
Is it safe?
Within the interpreter: yes.
In extensions: depends on the platform, but probably not.
The macros provide faster access to the C
M.-A. Lemburg wrote:
Hirokazu Yamamoto wrote:
Hello. I found several codes using PyMem_Free to free
allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
Is it safe?
Within the interpreter: yes.
In extensions: depends on the platform, but probably not.
The macros provide
Brett Cannon wrote:
2010/10/28 Kristján Valur Jónsson krist...@ccpgames.com:
I'm not sure what I'm actually proposing. But I certainly wasn't thinking
of a new fork of python. And not a new version 2.8 that gets all new 3.x
features backported.
I'm more thinking of a place where usability
Benjamin Peterson wrote:
2010/10/29 M.-A. Lemburg m...@egenix.com:
Brett Cannon wrote:
2010/10/28 Kristján Valur Jónsson krist...@ccpgames.com:
I'm not sure what I'm actually proposing. But I certainly wasn't thinking
of a new fork of python. And not a new version 2.8 that gets all new
3
Martin v. Löwis wrote:
It's obvious that a large proportion of the existing python-dev'ers will
not participate in such a project, but why should we try to stop someone
else to work on it ?
I propose to stop this discussion of theoretical projects, and only
restart it when someone actually
Barry Warsaw wrote:
On Oct 29, 2010, at 12:43 PM, Casey Duncan wrote:
I like Python 3, I am using it for my latest projects, but I am also keeping
Python 2 compatibility. This incurs some overhead, and basically means I am
still really only using Python 2 features. So in some respects, my
Victor Stinner wrote:
Hi,
Seven months after my first commit related to this issue, the full test suite
of Python 3.2 pass with ASCII, ISO-8859-1 and UTF-8 locale encodings in a non-
ascii source directory. It means that Python 3.2 now process correctly
filenames in all modules, build
Victor Stinner wrote:
Hi,
A PYTHONFSENCODING environment variable was added to Python 3.2: issue #8622.
This variable introduces an inconstency because the filesystem and the locale
encodings can now be different.
There are (at least) four issues related to this problem. We have 2
Martin v. Löwis wrote:
I don't know how hg manages this, but can't we preserve the tag
information of the tags that you've scheduled to be removed
in some place that can easily be pulled in but doesn't
affect the main repo size ?
Most certainly, and this is the plan already: we will keep
Dirkjan Ochtman wrote:
Okay, so let's summarize this thread so far:
Martin is in favor of removing some tags (certainly partial ones), but
is -0 on renaming them.
Tres is in favor of renaming release tags.
Georg advocates removing non-release tags, and doesn't care much about
renaming.
Nick Coghlan wrote:
On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg m...@egenix.com wrote:
I'm not sure whether throwing away history in form of such tags
is a good idea.
I don't know how hg manages this, but can't we preserve the tag
information of the tags that you've scheduled
Chris Bergstresser wrote:
Hi all --
I looked through the bug tracker, but I didn't see this listed. I
was trying to use the bz2 codec, but it seems like it's not very
useful in the current form (and I'm not sure if it's getting added
back to py3k, so maybe this is a moot point). It
Martin v. Löwis wrote:
So you are fine with publishing slightly incorrect metadata at PyPI
? I am not.
I really have no intuition for in how many cases the data will be
incorrect. However, if users find that the data is incorrect for
specific package, they ought to complain to the
Martin v. Löwis wrote:
-1 on always using wchar_t as well. Python's default is UCS2 and the
stable ABI should not change that.
It's not really Python's default. It is what configure.in does by
default. Python's default, on Linux, is UCS-4.
No, the default is UCS2 on all platforms and in
Martin v. Löwis wrote:
This sounds like the issues such a mix can cause are mostly
theoretical and don't really bother much in practice, so
PEP 384 on Windows does have a chance :-)
Actually, the CRT issues (FILE* in particular) have been
causing real crashes for many years, for many
Amaury Forgeot d'Arc wrote:
Hi,
2010/9/7 M.-A. Lemburg m...@egenix.com:
Ok. I'm fine with excluding Py_UNICODE from the stable ABI. However,
I think in the long run, I guess more support for wchar_t will then
be needed in the API, e.g. more convenient argument parsing.
Sure, we could add
Trigve wrote:
Hi,
I've found something strange while using unicode objects in embedded python.
Here is a situation. I'm creating a couple of unicode objects and then some
exception is thrown. While handling exception I create 2 unicode object. The
1.
one is created sucessfully but the
Victor Stinner wrote:
Hi,
Le jeudi 02 septembre 2010 11:13:22, vous avez écrit :
1. This function and PyUnicode_strcat are missing documentation.
It's Py_UNICODE_strcat(), not PyUnicode_strcat(). But yes,
Py_UNICODE_strcat()
is not documented. But I didn't found any doc for other
Georg Brandl wrote:
Hi Victor,
1. This function and PyUnicode_strcat are missing documentation.
2. Are you sure they need to be public APIs? What are they going to
be used for? (I'm not sure myself, but I think we usually have a
short notice here when new C APIs are added.)
If
Ronald Oussoren wrote:
On 28 Aug, 2010, at 12:29, Martin v. Löwis wrote:
- wide-unicode: this is a tricky one. I'm tempted to say that the
stable ABI should always use a Py_UNICODE that matches the platform's
wchar_t. Alternative proposals are welcome.
Sizeof(wchar_t) is 4 on OSX, but
Michael Foord wrote:
On 30/08/2010 17:35, Barry Warsaw wrote:
On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
Since the Linkage section of PEP 384 specifically states the
availability of a generic python3.dll that dynamically redirects to
the relevant python3y.dll to allow an extension
Daniel Stutzbach wrote:
On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg m...@egenix.com wrote:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes, and it's a pretty common situation. The fopen() that I call within a
DLL may not be the same fopen() called
Neil Hodgson wrote:
M.-A. Lemburg:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes. It is possible not only to mix C runtimes from different
vendors but different variants from a single vendor.
Historically, each vendor has shipped their own C
Georg Brandl wrote:
Am 21.08.2010 04:54, schrieb benjamin.peterson:
Author: benjamin.peterson
Date: Sat Aug 21 04:54:44 2010
New Revision: 84229
Log:
alias macintosh to mac_roman #843590
Modified:
python/branches/py3k/Doc/library/codecs.rst
Michael Foord wrote:
On 18/08/2010 15:34, Neal Becker wrote:
Is there any proposal to accommodate having parallel-installed multiple
versions of modules?
You can easily implement such a setup by placing the module versions
into a separate dir and then adding the right version dir to you
Éric Araujo wrote:
What you might want to do is add new type fields to PEP 345,
making it easier to identify and list packages that work as
plugins for applications, e.g.
Type: Plugin for MyCoolApp
The MyCoolApp could then use the Type-field to identify all
installed plugins, get their
P.J. Eby wrote:
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other package managers update
a central SQLite database cache
Michael Foord wrote:
On 03/08/2010 09:28, M.-A. Lemburg wrote:
P.J. Eby wrote:
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g
Tarek Ziadé wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby p...@telecommunity.com wrote:
..
So without specific examples of why this is a problem, it's hard to see why
a special Python-specific set of configuration files is needed to resolve
it, vs. say, encouraging application authors to
exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby p...@telecommunity.com wrote:
..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration files
Michael Foord wrote:
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby p...@telecommunity.com wrote:
..
So without specific examples of why this is a problem, it's hard to
see why
a special
Michael Foord wrote:
On 02/08/2010 20:36, M.-A. Lemburg wrote:
Michael Foord wrote:
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Ebyp...@telecommunity.com
wrote
Nick Coghlan wrote:
I wouldn't assume so - memoryview is meant to eventually support more
than just 1-D views of contiguous memory (see PEP 3118), so that
conversion doesn't seem intuitive to me.
In the example I'm passing in a single dimension contiguous memory
chunk to memoryview(), so in
Is this intended or should I open a bug report for it:
m = memoryview('abc')
m == 'abc'
True
str(m) == 'abc'
False
str(m)
'memory at 0x2b2bb6ee26d8'
I would have expected str(m) == 'abc'.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 15
Ronald Oussoren wrote:
On 27 Jun, 2010, at 11:48, Greg Ewing wrote:
Stefan Behnel wrote:
Greg Ewing, 26.06.2010 09:58:
Would there be any sanity in having an option to compile
Python with UTF-8 as the internal string representation?
It would break Py_UNICODE, because the internal size of
Terry Reedy wrote:
Comment on trust. Trust works both ways. So does distrust.
Asking contributors to give written licenses in addition to the license
implicit in the act of contribution is an act of distrust. It says
something like We worry that you might change you mind and sue, and a
Barry Warsaw wrote:
On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
Scott Dial wrote:
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
If you want to make it so a system can install a package in just one
location to be used by multiple Python installations
Brett Cannon wrote:
On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin jyass...@gmail.com wrote:
On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson dicki...@gmail.com wrote:
On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin jyass...@gmail.com wrote:
AC_PROG_CC is the macro that sets CFLAGS to -g -O2
Mark Dickinson wrote:
On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg m...@egenix.com wrote:
On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin jyass...@gmail.com wrote:
On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson dicki...@gmail.com wrote:
I'm not sure I understand the importance of allowing
Mark Dickinson wrote:
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg m...@egenix.com wrote:
Why do you think that the default -O2 is unwanted
Because it can cause debug builds of Python to be built with
optimization enabled, as we've already seen at least twice.
Then let me put it this way
M.-A. Lemburg wrote:
Mark Dickinson wrote:
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg m...@egenix.com wrote:
Why do you think that the default -O2 is unwanted
Because it can cause debug builds of Python to be built with
optimization enabled, as we've already seen at least twice
Mark Dickinson wrote:
On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg m...@egenix.com wrote:
Mark Dickinson wrote:
On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg m...@egenix.com wrote:
Why do you think that the default -O2 is unwanted
Because it can cause debug builds of Python to be built
Alexander Belopolsky wrote:
On Sun, Jun 27, 2010 at 5:57 AM, Mark Dickinson dicki...@gmail.com wrote:
On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl g.bra...@gmx.net wrote:
So -- if every dev adopted a Tool or Demo, that would be quite a
manageable piece of work, and maybe a few demos can be
Brett Cannon wrote:
On Wed, Jun 23, 2010 at 14:53, Brett Cannon br...@python.org wrote:
I finally realized why clang has not been silencing its warnings about
unused return values: I have -Wno-unused-value set in CFLAGS which
comes before OPT (which defines -Wall) as set in PY_CFLAGS in
Lennart Regebro wrote:
On Tue, Jun 22, 2010 at 20:07, James Y Knight f...@fuhm.net wrote:
Yeah. This is a real issue I have with the direction Python3 went: it pushes
you into decoding everything to unicode early, even when you don't care --
Well, yes, maybe even if *you* don't care. But
Scott Dial wrote:
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
If you want to make it so a system can install a package in just one
location to be used by multiple Python installations, then the version
number isn't enough. You also need to distinguish debug
Nick Coghlan wrote:
On Wed, Jun 23, 2010 at 4:09 AM, M.-A. Lemburg m...@egenix.com wrote:
It would be great if we could have something like the above as
builtin method:
x.split(''.as(x))
As per my other message, another possible (and reasonably intuitive)
spelling would be:
x.split
Guido van Rossum wrote:
[Just addressing one little issue here; generally I'm just happy that
we're discussing this issue in such detail from so many points of
view.]
On Mon, Jun 21, 2010 at 10:50 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
[...] Would urljoin(b_base, b_subdir) = bytes
Barry Warsaw wrote:
On Jun 21, 2010, at 12:34 PM, Toshio Kuratomi wrote:
I like the idea of having encoding information carried with the data.
I don't think that an ebytes type that can *optionally* have an encoding
attribute makes the situation less confusing, though.
Agreed. I think
Walter Dörwald wrote:
On 09.06.10 14:47, Nick Coghlan wrote:
On 09/06/10 22:18, Victor Stinner wrote:
Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
No, .transform() and .untransform() will be interface to same-type
codecs, i.e. ones that convert bytes to bytes or str to str
Victor Stinner wrote:
There are two opposite issues in the bug tracker:
#7475: codecs missing: base64 bz2 hex zlib ...
- reintroduce the codecs removed from Python3
#8838: Remove codecs.readbuffer_encode()
- remove the last part of the removed codecs
If I understood
Nick Coghlan wrote:
On 09/06/10 18:41, M.-A. Lemburg wrote:
The methods to be used will be .transform() for the encode direction
and .untransform() for the decode direction.
+1, although adding this for 3.2 would need an exception to the
moratorium approved (since it is adding new methods
Antoine Pitrou wrote:
On Wed, 09 Jun 2010 10:41:29 +0200
M.-A. Lemburg m...@egenix.com wrote:
The above example will read:
b'abc'.transform(hex)
b'616263'
b'616263'.untranform(hex)
b'abc'
This doesn't look right to me. Hex-encoded data is really text (it's
a textual
Victor Stinner wrote:
Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
No, .transform() and .untransform() will be interface to same-type
codecs, i.e. ones that convert bytes to bytes or str to str. As with
.encode()/.decode() these helper methods also implement type safety
Michael Foord wrote:
How does throwing away information represent moving forward?
I'm inclined to agree. There is no *need* to close these tickets now.
I have to say I am surprised by the current lack of momentum behind 3.x,
but I do know users who consider that their current investment in
Victor Stinner wrote:
Python 3.0 introduced PyUnicode_DecodeFSDefault() and
PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to
UTF-8 if getting the file system encoding failed or the encoding is unknown
(there is not nl_langinfo(CODESET) function).
UTF-8 is not a
Larry Hastings wrote:
M.-A. Lemburg wrote:
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look backwards compatible.
The C APIs exposed by the modules (e.g. the datetime module)
are used in lots of 3rd party extension modules and changing
them
larry.hastings wrote:
Author: larry.hastings
Date: Thu Mar 25 01:54:54 2010
New Revision: 79397
Log:
Backported PyCapsule from 3.1, and converted most uses of
CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look backwards
larry.hastings wrote:
Author: larry.hastings
Date: Thu Mar 25 01:54:54 2010
New Revision: 79397
Log:
Backported PyCapsule from 3.1, and converted most uses of
CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look backwards
Larry Hastings wrote:
M.-A. Lemburg wrote:
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look backwards compatible.
The C APIs exposed by the modules (e.g. the datetime module)
are used in lots of 3rd party extension modules and changing
them
Barry Warsaw wrote:
On Feb 03, 2010, at 11:59 AM, M.-A. Lemburg wrote:
How about using an optionally relative cache dir setting to let
the user decide ?
Why do we need that level of flexibility?
It's very easy to implement (see the code I posted) and gives
you a lot of control
On 03/02/2010 06:50, Barry Warsaw wrote:
As to the question of sibling directories or folder-per-folder I think
performance issues should be the deciding factor. There are file system
limitations to consider (but also a wide variety of file systems in
use). Do
the number of stat calls
Reid Kleckner wrote:
On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter collinwin...@google.com wrote:
Wouldn't it be possible to have the compiler approach work
in three phases in order to reduce the memory footprint and
startup time hit, ie.
1. run an instrumented Python interpreter to collect
Nick Coghlan wrote:
Barry Warsaw wrote:
On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
We deliberate don't document -U because its typical effect is break the
world - it makes all strings unicode in 2.x.
It only affects string literals, not all strings.
As an aside, I think this should
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python 2.6 as well.
Right, but there are a few issues in 2.6 that will be
exar...@twistedmatrix.com wrote:
On 03:21 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python
Collin Winter wrote:
On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg m...@egenix.com wrote:
Collin Winter wrote:
I think this idea underestimates a) how deeply the current CPython VM
is intertwined with the rest of the implementation, and b) the nature
of the changes required by these separate
Nick Coghlan wrote:
M.-A. Lemburg wrote:
BTW: I also doubt that Mercurial will make any of this easier.
It makes creating branches easier for non-committers, but the
problem of having to maintain the branches remains.
It greatly simplifies the process of syncing the branch with the main
Raymond Hettinger wrote:
On Jan 30, 2010, at 4:00 PM, Barry Warsaw wrote:
Abstract
This PEP describes an extension to Python's import mechanism which
improves sharing of Python source code files among multiple installed
different versions of the Python interpreter.
+1
+1
M.-A. Lemburg wrote:
Collin Winter wrote:
I added startup benchmarks for Mercurial and Bazaar yesterday
(http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we
can use them as more macro-ish benchmarks, rather than merely starting
the CPython binary over and over again. If you
Collin Winter wrote:
Hey MA,
On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Some years ago we discussed the idea of pluggable VMs for
Python. Wouldn't U-S be a good motivation to revisit this idea ?
We could then have a VM based on byte code using a stack
Collin Winter wrote:
I added startup benchmarks for Mercurial and Bazaar yesterday
(http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we
can use them as more macro-ish benchmarks, rather than merely starting
the CPython binary over and over again. If you have ideas for better
Benjamin Peterson wrote:
2010/1/25 Steve Howell showel...@yahoo.com:
I am interested in creating a patch to make deleting elements from the front
of Python list work in O(1) time by advancing the ob_item pointer.
How about just using a deque?
... or a stack:
Antoine Pitrou wrote:
Le samedi 23 janvier 2010 à 20:43 +0100, M.-A. Lemburg a écrit :
Now, we cannot easily remove this guessing since we're in stable
mode again with 3.1. Perhaps we should add a way to at least be
able to switch off this guessing, so that applications can be
tested
Martin v. Löwis wrote:
This all begs the question: why is there a default? and why is the
default a guess?
I have to admit that I was completely oblivious to this potential
pitfall, and mostly that's because in the most common case, I am working
with ASCII files.
You answered your own
Martin v. Löwis wrote:
No, but it's most likely a wrong guess, since text files don't
really have anything to do with what the user wants to see in
a user interface.
That also depends on the operating system. On Windows, there is
a long tradition of encoding all text in the system code
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
It's rather common to exchange text files between users... and
in form of XML and CSV files, these also tend to get used as
input for programs every now and then
For XML files, encoding should be taken care of by the XML layer
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
Hmm - what do you mean by normally? Normally, text files are meant
for human readers, not for exchange between programs.
It's rather common to exchange text files between users... and
in form of XML and CSV files, these also
Karen Tracey wrote:
On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
fuzzy...@voidspace.org.ukwrote:
On 21/01/2010 21:21, Martin v. Löwis wrote:
Where the default *file system encoding* is used (i.e. text files are
written or read without specifying an encoding)
I think you misunderstand
Michael Foord wrote:
On 20/01/2010 21:37, M.-A. Lemburg wrote:
The only supported default encodings in Python are:
Python 2.x: ASCII
Python 3.x: UTF-8
Is this true? I thought the default encoding in Python 3 was platform
specific (i.e. cp1252 on Windows). That means files written
Michael Foord wrote:
On 21/01/2010 11:15, M.-A. Lemburg wrote:
Michael Foord wrote:
On 20/01/2010 21:37, M.-A. Lemburg wrote:
The only supported default encodings in Python are:
Python 2.x: ASCII
Python 3.x: UTF-8
Is this true? I thought the default encoding
Michael Foord wrote:
As always: It's better not to rely on such defaults and explicitly
provide the encoding as parameter where possible.
Sure. I do worry that developers will still rely on the default behavior
assuming that Python 3 fixes their encoding problems and cause
David Malcolm wrote:
I'm thinking of making this downstream change to Fedora's site.py (and
possibly in future RHEL releases) so that the default encoding
automatically picks up the encoding from the locale:
def setencoding():
Set the string encoding used by the Unicode
David Malcolm wrote:
On Wed, 2010-01-20 at 22:37 +0100, M.-A. Lemburg wrote:
Note that pango isn't even doing the module reload hack; it's written in
C, and going in directly through the C API:
PyUnicode_SetDefaultEncoding(utf-8);
I should mention that I've seen at least one C module
Nick Coghlan wrote:
Guido van Rossum wrote:
On Wed, Jan 13, 2010 at 9:57 AM, sstein...@gmail.com Or, how about
just removing the antiquated use of environment variables altogether
from Python 3 and avoid the issue completely.
-1. They have their use, but more in controlled situations. If
Ralf Schmitt wrote:
M.-A. Lemburg m...@egenix.com writes:
Naive users won't have PYTHONPATH or any other Python environment
variables setup.
Really, if you know that you are going to run Python 3 instead of
Python 2 or vice-versa it's easy enough to run
You don't even know that you're
Brett Cannon wrote:
Michael has given me the hg transition/stdlib time slot at the language
summit this year. In regards to that I plan to lead a discussion on:
* where we are at w/ the Hg transition (Dirkjan should be there and I did a
blog post on this topic recently:
Olemis Lang wrote:
On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Hi,
Builtin open() function is unable to open an UTF-16/32 file starting with a
BOM if the encoding is not specified (raise an unicode error). For an UTF-8
file starting with a BOM,
Victor Stinner wrote:
(2) Check for a BOM while reading or detect it before?
Everybody agree that checking BOM is an interesting option and should not be
limited to open().
Marc-Andre proposed a codecs.guess_file_encoding() function accepting a file
name or a binary file-like object: it
Guido van Rossum wrote:
On Fri, Jan 8, 2010 at 6:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
Victor Stinner victor.stinner at haypocalc.com writes:
I wrote a new version of my patch (version 3):
* don't change the default behaviour: use open(filename, encoding=BOM) to
check the BOM is
Tres Seaver wrote:
M.-A. Lemburg wrote:
Shouldn't this encoding guessing be a separate function that you call
on either a file or a seekable stream ?
After all, detecting encodings is just as useful to have for non-file
streams.
Other stream sources typically have out-of-band ways
Karen Tracey wrote:
In testing some existing code with the 2.7 alpha release, I've run into:
TypeError: Unicode-objects must be encoded before hashing
when the existing code tries to pass unicode objects to hashlib.sha1 and
hashlib.md5. This is, I believe, due to changes made for
Michael Foord wrote:
On 15/12/2009 11:23, M.-A. Lemburg wrote:
Karen Tracey wrote:
In testing some existing code with the 2.7 alpha release, I've run into:
TypeError: Unicode-objects must be encoded before hashing
when the existing code tries to pass unicode objects to hashlib.sha1
Tarek Ziadé wrote:
On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg m...@egenix.com wrote:
[..]
I've refactored distutils/ and site.py so they work with this new
module, and added deprecation warnings in distutils.sysconfig.
I think we really need to do something about these kinds
Tarek Ziadé wrote:
== code, status, next steps ==
The code of the module can be viewed here, it's a revamp of
distutils.sysconfig:
http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
I've refactored distutils/ and site.py so
301 - 400 of 989 matches
Mail list logo
