On 22.12.2012 21:36, Terry Reedy wrote:
On 12/22/2012 1:30 PM, Cron Daemon wrote:
abort: error: Connection timed out
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
As a
On 03.02.2013 19:33, Éric Araujo wrote:
I vote for removing the distutils is frozen principle.
I’ve also been thinking about that. There have been two exceptions to
the freeze, for ABI flags in extension module names and for pycache
directories. When the stable ABI was added and MvL wanted
On 17.02.2013 11:11, Nick Coghlan wrote:
FYI
-- Forwarded message --
From: Nick Coghlan ncogh...@gmail.com
Date: Sun, Feb 17, 2013 at 8:10 PM
Subject: PEP 426 is now the draft spec for distribution metadata 2.0
To: DistUtils mailing list\\ distutils-...@python.org
On 19.02.2013 11:28, Nick Coghlan wrote:
On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2013 11:11, Nick Coghlan wrote:
I'm not against modernizing the format, but given that version 1.2
has been out for around 8 years now, without much following,
I think we
On 19.02.2013 14:40, Nick Coghlan wrote:
On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg m...@egenix.com wrote:
* PEP 426 doesn't include any mention of the egg distribution format,
even though it's the most popular distribution format at the moment.
It should at least include the location
On 19.02.2013 14:40, Nick Coghlan wrote:
On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg m...@egenix.com wrote:
On 19.02.2013 11:28, Nick Coghlan wrote:
On Tue, Feb 19, 2013 at 7:37 PM, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2013 11:11, Nick Coghlan wrote:
I'm not against modernizing
On 19.02.2013 23:01, Daniel Holth wrote:
On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg m...@egenix.com wrote:
On 19.02.2013 14:40, Nick Coghlan wrote:
On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg m...@egenix.com wrote:
* PEP 426 doesn't include any mention of the egg distribution format
On 20.02.2013 03:37, Paul Moore wrote:
On 20 February 2013 00:54, Fred Drake f...@fdrake.net wrote:
I'd posit that anything successful will no longer need to be added to
the standard library, to boot. Packaging hasn't done well there.
distlib may be the exception, though. Packaging tools
On 20.02.2013 00:16, Daniel Holth wrote:
On Tue, Feb 19, 2013 at 5:10 PM, M.-A. Lemburg m...@egenix.com wrote:
On 19.02.2013 23:01, Daniel Holth wrote:
On Tue, Feb 19, 2013 at 4:34 PM, M.-A. Lemburg m...@egenix.com wrote:
On 19.02.2013 14:40, Nick Coghlan wrote:
On Tue, Feb 19, 2013 at 11
Reminds me of the encoding attacks that were possible in earlier
versions of Python... you could have e.g. an email processing
script run the Python test suite by simply sending a specially
crafted email :-)
On 21.02.2013 13:04, Christian Heimes wrote:
Am 21.02.2013 11:32, schrieb Antoine
On 23.04.2013 17:15, Barry Warsaw wrote:
On Apr 22, 2013, at 06:22 PM, Guido van Rossum wrote:
You can ask the same question about all the other codecs. (And that
question has indeed been asked in the past.)
Except for rot13. :-)
The fact that you can do this instead *is* a bit odd. ;)
On 23.04.2013 17:47, Guido van Rossum wrote:
On Tue, Apr 23, 2013 at 8:22 AM, M.-A. Lemburg m...@egenix.com wrote:
Just as reminder: we have the general purpose
encode()/decode() functions in the codecs module:
import codecs
r13 = codecs.encode('hello world', 'rot-13')
These interface
On 23.04.2013 23:37, Nick Coghlan wrote:
On 24 Apr 2013 01:25, M.-A. Lemburg m...@egenix.com wrote:
On 23.04.2013 17:15, Barry Warsaw wrote:
On Apr 22, 2013, at 06:22 PM, Guido van Rossum wrote:
You can ask the same question about all the other codecs. (And that
question has indeed been
On 23.04.2013 19:24, Guido van Rossum wrote:
On Tue, Apr 23, 2013 at 9:04 AM, M.-A. Lemburg m...@egenix.com wrote:
On 23.04.2013 17:47, Guido van Rossum wrote:
On Tue, Apr 23, 2013 at 8:22 AM, M.-A. Lemburg m...@egenix.com wrote:
Just as reminder: we have the general purpose
encode()/decode
On 30.04.2013 11:15, Paul Moore wrote:
Before I raise a bug for this, can someone confirm if I've simply missed
something? I don't see any way, either in the docs or in the helpstrings
from the codecs, of listing the codecs that have been registered.
FWIW, I picked this up when I was looking
On 30.04.2013 11:52, Paul Moore wrote:
On 30 April 2013 10:42, M.-A. Lemburg m...@egenix.com wrote:
It would be possible to get a list of registered codec search functions,
but there's no API to ask the search functions for a list of supported
codecs.
OK, so there's no way to determine
On 12.05.2013 06:03, Benjamin Peterson wrote:
The long anticipated emergency 2.7.5 release has now been tagged. It
will be publicly announced as binaries arrive.
Originally, I was just going to cherrypick regression fixes onto the
2.7.4 release and release those as 2.7.5. I started to this
On 15.05.2013 19:11, Benjamin Peterson wrote:
2013/5/15 M.-A. Lemburg m...@egenix.com:
On 12.05.2013 06:03, Benjamin Peterson wrote:
The long anticipated emergency 2.7.5 release has now been tagged. It
will be publicly announced as binaries arrive.
Originally, I was just going to cherrypick
On 29.05.2013 21:19, Antoine Pitrou wrote:
Hi,
On Wed, 29 May 2013 21:59:21 +0300
Carlos Nepomuceno carlosnepomuc...@outlook.com wrote:
[1] pybench - run the standard Python PyBench benchmark suite. This is
considered
an unreliable, unrepresentative benchmark; do not base decisions
On 08.06.2013 09:45, Serhiy Storchaka wrote:
Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py,
*.c and *.h files. I
think it would be worthwhile to update the source code and documentation for
more modern RFCs.
Thanks for creating such a list.
BTW: What is
Zooko O'Whielacronx wrote:
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
What binaries are you talking about?
I mean extension modules with native code, which means .so shared
library files on unix.
Those will not load unless they are for the right UCS-version
Tarek Ziadé wrote:
Hello
Here's a wrapup of the Distutils-SIG discussion
we had on the static metadata topic.
I realize that it's a good thing to send in.
python-dev such wrapup on distutils design
decisions, to keep everyone informed and get
more feedback when required.
I will try
Zooko O'Whielacronx wrote:
Folks:
I'm sorry, I think I didn't make my concern clear. My users, and lots
of other users, are having a problem with incompatibility between
Python binary extension modules. One way to improve the situation
would be if the Python devs would use their bully
M.-A. Lemburg wrote:
Also note that Python will complain loudly when you try to load
a UCS2 extension in a UCS4 build and vice-versa. We've made sure
that any extension using the Python Unicode C API has to be built
for the same UCS version of Python. This is done by using different
names
Antoine Pitrou wrote:
Hello,
I am neutral on the idea of adding argparse. However, I'm -1 on deprecating
optparse. It is very widely used (tons of scripts use it), and ok for many
uses;
deprecating it is totally unhelpful and gratuitous.
You can add me to that camp as well:
+0 on
James Y Knight wrote:
On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote:
Distributions should really not be put in charge of upstream
coding design decisions.
I don't think you can blame distros for this one
From PEP 0261:
It is also proposed that one day --enable-unicode will just
Ronald Oussoren wrote:
On 26 Sep, 2009, at 14:46, Barry Scott wrote:
I'm working with http://svn.python.org/projects/python/trunk on Mac OS
X 10.6.1
using Apples xcode gcc 4.2.1.
When I run the following commands:
./configure --enable-framework --with-universal-archs=32-bit | tee
Ronald Oussoren wrote:
Use:
./configure --enable-framework --enable-universalsdk=/
The --with-universal-archs flag selects whichs architectures should be
included when you build a universal binary, defaulting to 32-bit.
The Python default on 10.6 is 64-bit, so wouldn't it be better
Ronald Oussoren wrote:
On 29 Sep, 2009, at 18:17, M.-A. Lemburg wrote:
Ronald Oussoren wrote:
Use:
./configure --enable-framework --enable-universalsdk=/
The --with-universal-archs flag selects whichs architectures should be
included when you build a universal binary, defaulting
Eric Smith wrote:
Martin v. Löwis wrote:
Steven Bethard wrote:
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting.
I don't agree that we should do that. I see
Tarek Ziadé wrote:
I'm not proposing to debate the merits of all of the options here.
However, if a 2.6.4 release is to be pushed out quickly for other
reasons, a one-time window of opportunity would be available and it
would be prudent to at least consider the possibility of a distutils fix.
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
If this choice wins here, it means that setuptools and the stdlib are
tied together, and that the
M.-A. Lemburg wrote:
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
If this choice wins here, it means that setuptools and the stdlib are
tied
Senthil Kumaran wrote:
On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
Greetings effbot. :)
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
The only question is, given that 2.6.x is supposed to be a bug-fix branch,
do we
want to fix that incompatibility with a widely deployed existing piece of
software? Whether or not the
Chris Withers wrote:
M.-A. Lemburg wrote:
We've implemented our own bdist_egg now which doesn't use setuptools
and will start to ship eggs in addition to our prebuilt format with
the next releases.
Egg-cellent ;-)
Any chance this tool is open source? Better yet, could it make its way
Chris Withers wrote:
M.-A. Lemburg wrote:
mxSetup.py, the module implementing all our distutils extensions,
is available in egenix-mx-base which is open source:
http://www.egenix.com/products/python/mxBase/
I have memories of mxBase having a load of other stuff in it too?
Yep, lots
Chris Withers wrote:
M.-A. Lemburg wrote:
The complicated stuff does belong somewhere else, but the
basic things need to go into the filename
But everyone's basic things are different.
The really basic stuff is the same for everyone since it's
dictated by the way Python works on computers
P.J. Eby wrote:
At 03:18 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
Note how the package name is mangled... easy_install requires this.
The file name also doesn't tell you that the above is for
a UCS2 Python build. Again, easy_install fails with that information
added to the py2.6 version
P.J. Eby wrote:
At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
It goes a bit in the direction of what we had in mind with writing
for our clients: a tool that looks at the Python installation and
automatically finds/downloads/installs the right package from
our website. Only that we wanted
David Lyon wrote:
Distutils for windows is very, very dead.. grave-ware in-fact.
Now that is not true at all. We have a native Windows installer
(bdist_wininst) and an MSI builder (bdist_msi) that both work
great on Windows.
Plus there are add-ons for other installers such as NSIS and
Zooko O'Whielacronx wrote:
+1
For a large number of people [1, 2, 3], setuptools is already a
critical part of Python. Make it official. Let everyone know that
future releases of Python will not break setuptools/Distribute, and
that they can rely on backwards-compatibility with the myriad
Zooko O'Whielacronx wrote:
Dear MAL and python-dev:
I failed to explain the problem that users are having. I will try
again, and this time I will omit my ideas about how to improve things
and just focus on describing the problem.
Some users are having trouble using Python packages
Zooko O'Whielacronx wrote:
Thanks for the reply, MAL.
How would we judge whether Distribute is ready for inclusion in the
Python standard lib? Maybe if it has a few more releases, leaving a
trail of closed: fixed issue tickets behind it?
I guess it'll just have to take the usual path of
Ronald Oussoren wrote:
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote:
If we do go for a change, we should use sizeof(wchar_t)
as basis for the new default - on all platforms that
provide a wchar_t type.
I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's
that deal
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and pip use setuptools as an important piece
Ronald Oussoren wrote:
On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote:
Ronald Oussoren wrote:
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote:
If we do go for a change, we should use sizeof(wchar_t)
as basis for the new default - on all platforms that
provide a wchar_t type.
I'd be -1
David Lyon wrote:
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers ch...@simplistix.co.uk
wrote:
Well yeah, and the only sane way I can think to handle this is to have a
metadata file that gets uploaded with each distribution that covers all
these things (and the other things that other
Adam Olsen wrote:
On Sun, Sep 20, 2009 at 10:17, Zooko O'Whielacronx zoo...@gmail.com wrote:
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
AFAIK, C extensions should fail loading when they have the wrong UCS2/4
setting.
That would be an improvement!
Tarek Ziadé wrote:
On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Who would I need to contact for the PyPI side to work out
an upload_url distutils command ?
I am not sure to understand. How upload_url will differ from the
register command
that let you upload
I have just a few comments to make, so I'm trimming the long quote
a bit...
Tarek Ziadé a écrit :
== Version comparison ==
One very important point: we will not force the community to use the
scheme described in PEP 386, but *there is* already a
de-facto convention on version schemes at
Tarek Ziadé wrote:
On Thu, Oct 8, 2009 at 10:38 AM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Who would I need to contact for the PyPI side to work out
an upload_url distutils command ?
I am not sure
Tarek Ziadé wrote:
On Thu, Oct 8, 2009 at 1:27 PM, M.-A. Lemburg m...@egenix.com wrote:
== The fate of setup.py, and static metadata ==
So we are going to separate the metadata description from setup.py, in
a static configuration file, that can be open and read by anyone
without
running
Tarek Ziadé wrote:
On Thu, Oct 8, 2009 at 4:55 PM, M.-A. Lemburg m...@egenix.com wrote:
OTOH, the register command sends the meta-data directly to
the PyPI database, so it doesn't even need another file
for storing away the meta data.
Unless I'm missing something important (which I probably
David Lyon wrote:
On Thu, 08 Oct 2009 09:35:57 +0200, M.-A. Lemburg m...@egenix.com wrote:
One could say that much of the setuptools cloud came about because of
the lack of the queryable download url. Setuptools does a lot of work
here to 'work-around' the ommission on pypi of a package
Tarek Ziadé wrote:
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg m...@egenix.com wrote:
I know that the issue tracker for PyPI is (still) on SF, but
development appear to happen elsewhere and I can't find any
contact information on the PyPI web pages.
Everything is provided here:
http
Christian Heimes wrote:
Nick Coghlan wrote:
Importing yet-another-module for use in site.py doesn't sound like a
great idea, so it may make sense to migrate that information into the
sys module is this approach is taken. sys.name is a little generic
though - something more explicit like
Martin v. Löwis wrote:
I know that the issue tracker for PyPI is (still) on SF, but
development appear to happen elsewhere and I can't find any
contact information on the PyPI web pages.
PyPI discussion takes place mostly on catalog-sig.
Ok, then I'll sign up there.
Thanks,
--
Marc-Andre
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.
It'll also take a long while before all Python implementations
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate
platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.
It'll also take
Martin v. Löwis wrote:
id (required):
lower case identifier, for example cpython, ironpython, jython,
pypy
Doing some bike-shedding: I'd like to not use cpython as the name of
the python.org implementation. This term, I believe, was coined around
JPython, somehow making the
Christian Heimes wrote:
sys.implementation
--
platform (required):
platform or language of the implementation, for example C, .NET,
Java
I'd call this attribute language. We already have sys.platform with
a different meaning.
Possible values would then be C, C#, Java,
Nick Coghlan wrote:
M.-A. Lemburg wrote:
sys.userdirsuffix
-
sys.userdirsuffix is an implementation and platform specific string that
is used to construct the path for the user site directory as explained
in PEP 370. The string contains the implementation name as well
Barry Warsaw wrote:
Are we on track to release 2.6.4 final this Sunday or do we need another
rc?
Yesterday, Tarek committed another setuptools related fix and said that
he was going to run a bunch of build tests locally. Tarek, how did that
go?
Please note that issue 7064 is still open
Martin v. Löwis wrote:
It would be nice to get this issue resolved out for 2.6.4:
http://bugs.python.org/issue4120
The problem is that extensions built with 2.6.x will not work
when used with a User-only installation of Python on machines that
don't already have the MS VC90 CRT DLLs
P.J. Eby wrote:
At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
Are we on track to release 2.6.4 final this Sunday or do we need
another rc?
Yesterday, Tarek committed another setuptools related fix and said
that he was going to run a bunch of build tests locally. Tarek, how
did that go?
Barry Warsaw wrote:
On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote:
Then I'd suggest to wait another week with 2.6.4 to give you a
chance to look at the patch.
That's not a good option, IMO. We have a known broken 2.6.3 out there
and we owe it to our users to correct our mistake
Barry Warsaw wrote:
On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote:
Would it be reasonable to shorten that period, if the fix for the
mentioned problem gets ready for prime time earlier ?
I think there are many 2.6.x bugs queued up for after 2.6.4 is
released. I'm not at all opposed
instead. The system time part will then always be 0.0.
The module exports one public API:
def systimes():
Return the current timer values for measuring user and system
time as tuple of seconds (user_time, system_time).
Copyright (c) 2006, Marc-Andre Lemburg (m
Tarek Ziadé wrote:
Hello,
Since the addition of PEP 370, (per-user site packages), site.py and
distutils/command/install.py are *both* providing the various
installation directories for Python,
depending on the system and the Python version.
We have also started to discuss lately in
Antoine Pitrou wrote:
Guido van Rossum guido at python.org writes:
Is it even wort doing a 2.7 release? Isn't the effort better spent on
3.2 alone? (Note, these aren't rhetorical questions. It's well
possible that there are good reasons for pushing along with 2.7. Maybe
considering those
Raymond Hettinger wrote:
In all these matters, I think the users should get a vote. And that
vote should be cast with their decision to stay with 2.x, or switch to
3.x, or try to support both. We should not muck with their rational
decision making by putting carrots in one pile and
Guido van Rossum wrote:
I've checked draft (!) PEP 3003, Python Language Moratorium, into
SVN. As authors I've listed Jesse, Brett and myself.
On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm bracing myself for
fierce
Martin v. Löwis wrote:
2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
object), which means it is better for people wanting to ease transition to
3.x.
But of course, as Martin said, few people will want to support 2.7 only and
not
2.6.
Since 2.7 will be closer
Nick Coghlan wrote:
Lennart Regebro wrote:
I also would really like to see a real port of the bytes class to 2.6,
but I have a vague memory that there was some reason that wouldn't
work.
Not so much that it wouldn't work, but that the interfaces to support
using it effectively really
Tarek Ziadé wrote:
On Mon, Nov 16, 2009 at 8:15 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
[..]
I've brought the issue of Makefile and pyconfig.h being needed for distutils
to the attention of every new Fedora python maintainer since the package
split was made. The current maintainer,
The wiki page for porting to 3.x says:
http://wiki.python.org/moin/PortingExtensionModulesToPy3k
long/int Unification
In Python 3.0, there is only one integer type. It is called int on the Python
level, but actually
corresponds to 2.x's long type. In the C-API, PyInt_* functions are replaced
Eric Smith wrote:
M.-A. Lemburg wrote:
Since package developers are just starting to port things to 3.x and
many appear to be considering supporting both 2.7 and 3.1 (including
myself), I find it a bit strange that such an import aliasing header
was removed in 3.1.
There's some discussion
Martin v. Löwis wrote:
IMHO, that's not really a good way to encourage people to try to provide
a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make
it easier for developers by providing more standard helpers like
the removed intobject.h header file.
I think it's better
Mark Dickinson wrote:
On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg m...@egenix.com wrote:
Thanks for pointing me to the that ticket.
Looks like Guido already commented on this, so intobject.h could
be revived in some form.
I'm wondering how a resurrected intobject.h should be used
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
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
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
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
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,
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:
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
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
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
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
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
701 - 800 of 989 matches
Mail list logo
