On 2008-05-28 14:02, Christian Heimes wrote:
M.-A. Lemburg schrieb:
I have a feeling that we should be looking for better merge
tools, rather than implement code changes that cause more trouble
than do good, just because our existing tools aren't smart
enough.
We don't have better tools
On 2008-05-23 01:15, Bill Janssen wrote:
That's all fine, but then I'm missing the OpenSSL license and
attribution notice somewhere in the installer, the README of the
installation or elsewhere.
Good point. We need this for both the ssl module and the hashlib
module.
FYI: I've opened ticket
On 2008-05-19 00:59, Dan Lenski wrote:
Hi all,
I've written a small C extension to submit commands to SCSI devices via
Linux's sg_io driver (for a camera hacking project). The extension is
just a wrapper around a couple ioctl()'s with Pythonic exception handling
thrown in. One of my
On 2008-05-20 00:46, Jesus Cea wrote:
Trent Nelson wrote:
| I downloaded the source that includes AES encryption, for no reason
| other than it was first on the list. I'm now wondering if we should
| only be importing the 'NC' source that doesn't contain any
| encryption? Jesus, does pybsddb
On 2008-05-20 10:22, Martin v. Löwis wrote:
I'd like to propose a new environment variable PYTHONSTDOUTENCODING.
This is meant to solve various problems that people had with Python
not detecting their terminal encoding correctly; it would override
any detection that Python would use for
On 2008-05-20 12:16, Thomas Wouters wrote:
On Tue, May 20, 2008 at 10:41 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-05-20 10:22, Martin v. Löwis wrote:
I'd like to propose a new environment variable PYTHONSTDOUTENCODING.
This is meant to solve various problems that people had
On 2008-05-20 20:23, Martin v. Löwis wrote:
Writing Unicode to stdout will still use the default encoding
ASCII to convert it to an 8-bit string.
That's not true.
Are you sure ?
setenv LC_ALL de_DE.utf8
python2.5
Python 2.5 (r25:51908, May 9 2007, 00:53:06)
u = u'äöü'
On 2008-05-18 22:24, Brett Cannon wrote:
On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
doing the renaming in the 2.x branch, but it appears that
the only reason is to get used to the new
On 2008-05-17 16:59, Alexandre Vassalotti wrote:
On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I'd like to bring a potential problem to attention that is caused
by the recent module renaming approach:
Object serialization protocols like e.g. pickle usually store
I'd like to bring a potential problem to attention that is caused
by the recent module renaming approach:
Object serialization protocols like e.g. pickle usually store the
complete module path to the object class together with the object.
They access this module path by looking at the
On 2008-05-12 04:34, Brett Cannon wrote:
For the sake of argument, let's consider the Queue module. It is now
named queue. For 2.6 I plan on having both Queue and queue listed in
the index, with Queue deprecated with instructions to use the new
name.
But what to do about all the references.
On 2008-05-15 22:33, A.M. Kuchling wrote:
Python 2.6 renames the ConfigParser module to be configparser.
Distutils imports ConfigParser in various places. I just made a
commit updating the import in one places, and then noticed that part
of commit r63248, which made the same change, was
On 2008-05-16 16:15, Nick Coghlan wrote:
Alexander Belopolsky wrote:
Yannick Gingras ygingras at ygingras.net writes:
2) Where can I find the symbolic name in C?
Use standard C library char* strerror(int errnum) function. You can see
an example usage in Modules/posixmodule.c
On 2008-05-16 17:02, Alexander Belopolsky wrote:
On Fri, May 16, 2008 at 10:52 AM, Yannick Gingras [EMAIL PROTECTED] wrote:
print e
[Errno 21] Is a directory
So now I am not sure what OP is proposing. Do you want to replace 21
with EISDIR in the above?
Yes, that's what I had in mind.
In
On 2008-05-14 14:15, Jesse Noller wrote:
On Wed, May 14, 2008 at 5:45 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Martin v. Löwis schrieb:
I'm worried whether it's stable, what user base it has, whether users
(other than the authors) are lobbying for inclusion. Statistically,
it seems
On 2008-05-10 01:18, Martin v. Löwis wrote:
Is there a tool available that can convert 2.x code automagically
to the .format() method syntax ?
Just did a quick grep of our code base and it has some 2000 lines of code
that would need to be changed.
Why do you think this code needs to change?
On 2008-05-08 13:59, Barry Warsaw wrote:
On May 8, 2008, at 7:54 AM, Benjamin Peterson wrote:
On Thu, May 8, 2008 at 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
Since the trunk buildbots appear to be mostly happy (well those that are
connected anyway), and because I couldn't get the
Is there a tool available that can convert 2.x code automagically
to the .format() method syntax ?
Just did a quick grep of our code base and it has some 2000 lines of code
that would need to be changed.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the
On 2008-05-09 15:29, [EMAIL PROTECTED] wrote:
mal Is there a tool available that can convert 2.x code automagically
mal to the .format() method syntax ?
mal Just did a quick grep of our code base and it has some 2000 lines
mal of code that would need to be changed.
I suggested
On 2008-05-04 18:14, Christian Heimes wrote:
First, Skip, I *only* care about the default behavior. There's already
a way to do it differently: PYTHONPATH. So, Fred, I think what you're
arguing for is to drop this feature entirely. Or is there some other
use for a new way to allow users to
On 2008-05-04 21:57, Christian Heimes wrote:
M.-A. Lemburg schrieb:
PYTHONPATH is lacking one feature which is important for lots of
packages and setuptools. The directories in PYTHONPATH are just added to
sys.path. But setuptools require a site package directory. Maybe a new
env var
On 2008-04-23 07:26, Terry Reedy wrote:
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| I certainly agree that if the target set of documents is small enough it
|
| Ok. What advantage would you (or somebody working on a similar project)
| gain if chardet was part of
On 2008-04-21 23:31, Martin v. Löwis wrote:
This is useful when you get a hunk of data which _should_ be some
sort of intelligible text from the Big Scary Internet (say, a posted
web form or email message), and you want to do something useful with
it (say, search the content).
I don't
[CCing python-dev again]
On 2008-04-22 12:38, Greg Wilson wrote:
I don't think that should be part of the standard library. People
will mistake what it tells them for certain.
[etc]
These are all good arguments, but the fact remains that we can't control
our inputs (e.g., we're archiving
On 2008-04-22 18:33, Bill Janssen wrote:
The 2002 paper A language and character set determination method
based on N-gram statistics by Izumi Suzuki and Yoshiki Mikami and
Ario Ohsato and Yoshihide Chubachi seems to me a pretty good way to go
about this.
Thanks for the reference.
Looks like
On 2008-04-11 19:10, Sérgio Durigan Júnior wrote:
Hi all,
My question is simple: is there any problem when installing/using both
32- and 64-bit Python's on the same machine? I'm more concerned about
header files (those installed under /usr/include/python-2.x), because as
far as I could see
On 2008-04-11 20:21, Sérgio Durigan Júnior wrote:
Hi Lemburg,
On Fri, 2008-04-11 at 19:38 +0200, M.-A. Lemburg wrote:
On 2008-04-11 19:10, Sérgio Durigan Júnior wrote:
Hi all,
My question is simple: is there any problem when installing/using both
32- and 64-bit Python's on the same
On 2008-04-11 22:25, Sérgio Durigan Júnior wrote:
On Fri, 2008-04-11 at 22:06 +0200, M.-A. Lemburg wrote:
Hmm, right. I tried to modify the installation path (using --libdir
in ./configure) to /usr/lib64, but some *.pyo objects still are
installed under /usr/lib. AFAIK, these objects
On 2008-03-27 09:20, Christian Heimes wrote:
Neal Norwitz schrieb:
Christian,
Please fix the build on the various buildbots that are failing or
revert your changes for unicode literals. The build failures started
to occur at r61953. There were several more (~5) follow up checkins.
You
On 2008-03-26 07:11, Martin v. Löwis wrote:
For binary representations, we already have the struct module to handle
the parsing, but for byte sequences with embedded ASCII digits it's
reasonably common practice to use strings along with the respective type
constructors.
Sure, but why
On 2008-03-24 09:22, Lennart Regebro wrote:
I think 2to3 is a procedure that will work well for library type
projects with a reasonably small set of developers that make regular
releases. There you can release both a python 2 and a python 3 version
of the module, for example.
...
So, in
On 2008-03-21 14:47, Phillip J. Eby wrote:
So, to accomplish this, we (for some value of we) need to:
1. Hash out consensus around what changes or enhancements are needed
to PEP 262, to resolve the previously-listed open issues, those that
have come up since (namespace packages, dependency
On 2008-03-21 22:32, Martin v. Löwis wrote:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built,
On 2008-03-21 22:21, Phillip J. Eby wrote:
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
I guess the only way to support all of these variants is
to use a filesystem based approach, e.g. by placing a file
with a special extension into some dir on sys.path.
The database logic could
On 2008-03-18 18:05, [EMAIL PROTECTED] wrote:
I'm reviving a very old thread based on discussions with Martin at pycon.
Sent: Monday, 23 July 2007 5:12 PM
Subject: Re: [Distutils] distutils.util.get_platform() for Windows
Rather than forcing everyone to read the context, allow me to
On 2008-03-20 13:42, Thomas Heller wrote:
M.-A. Lemburg schrieb:
About the platform.py changes: if someone could provide the return
values of sys.getwindowsversion() for 64bit versions of Windows
XP and Vista, I could add support for it (don't have a 64bit version
of Windows available
On 2008-03-20 13:55, M.-A. Lemburg wrote:
On 2008-03-20 13:42, Thomas Heller wrote:
M.-A. Lemburg schrieb:
About the platform.py changes: if someone could provide the return
values of sys.getwindowsversion() for 64bit versions of Windows
XP and Vista, I could add support for it (don't have
On 2008-03-20 21:34, Paul Moore wrote:
Also, setuptools-based packages *can* build bdist_wininst
installers. (In fact, if memory serves, I added that feature at your
request.)
I know. python setup.py bdist_wininst. And thank you for adding it.
But again you miss my point. People are
On 2008-03-02 14:47, Christian Heimes wrote:
Alex Martelli wrote:
Yep, but please do keep the PyUnicode for str and PyString for bytes
(as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
task of porting existing extensions... the bytearray functions should
no doubt be
On 2008-03-02 20:39, Bill Janssen wrote:
Why not also make unicode() the default type constructor and only
keep str() as alias to simplify porting (perhaps with a warning) ?
The term string is just too overloaded with all kinds of
misinterpretations. The term string just refers to a string of
On 2008-03-02 23:11, Greg Ewing wrote:
M.-A. Lemburg wrote:
Why not also make unicode() the default type constructor and only
keep str() as alias to simplify porting (perhaps with a warning) ?
-1 on making us type 7 characters instead of
3 all over the place.
Oh well... how about text
On 2008-02-23 00:46, Colin Walters wrote:
On Fri, Feb 22, 2008 at 4:23 PM, John Dennis [EMAIL PROTECTED] wrote:
Python programs which use Unicode string objects for their i18n and
which link to C libraries expecting UTF-8 but which have a CPython
binding which only uses 's' or 's#'
On 2008-02-13 08:02, Andrew MacIntyre wrote:
Christian Heimes wrote:
Andrew MacIntyre wrote:
I tried a LIFO stack implementation (though I won't claim to have done it
well), and found it slightly slower than no freelist at all. The
advantage of such an approach is that the known size of the
On 2008-02-13 12:56, Andrew MacIntyre wrote:
I'm not that interested in debating the detail of exactly how big the
prospective LIFO freelists are - I just want to see the situation
resolved with maximum utilisation of memory for minimum performance
penalty. To that end, +1 from me for
On 2008-02-08 08:21, Martin v. Löwis wrote:
One of the hopes of having a custom allocator for Python was to be
able to get rid off all free lists. For some reason that never happened.
Not sure why. People were probably too busy with adding new
features to the language at the time ;-)
On 2008-02-08 19:28, Christian Heimes wrote:
In addition to the pure performance aspect, there is the issue of memory
utilisation. The current trunk code running the int test case in my
original post peaks at 151MB according to top on my FreeBSD box, dropping
back to about 62MB after the dict
On 2008-02-07 14:09, Andrew MacIntyre wrote:
Probably in response to the same stimulus as Christian it occurred to me
that the freelist approach had been adopted long before PyMalloc was
enabled as standard (in 2.3), and that much of the performance gains
between 2.2 and 2.3 were in fact due
Hi Christian,
could you explain how you came up with the 256 entry limit ?
It appears to be rather low and somehow arbitrary.
I understand that some limit is required, but since these
objects get created a lot (e.g. for bound methods), setting the
limit too low will significantly slow down the
On 2008-01-27 08:14, Raymond Hettinger wrote:
. You may disagree, but that doesn't make it nuts.
Too many thoughts compressed into one adjective ;-)
Deprecating int(float)--int may not be nuts, but it is disruptive.
Having both trunc() and int() in Py2.6 may not be nuts, but it is
On 2008-01-25 21:26, Steve Holden wrote:
Antoine Pitrou wrote:
Raymond Hettinger python at rcn.com writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3.
No one will be surprised (even folks who just use Excel or VB). It
is foolhardy to be a purist and rage against the
I don't really understand what all this has to do with per user
site-packages.
Note that the motivation for having per user site-packages
was to:
* address a common request by Python extension package users,
* get rid off the hackery done by setuptools in order
to provide this.
As such
On 2008-01-20 19:30, Christian Heimes wrote:
Yet another python executable could solve the issue, named pythons as
python secure.
/*
gcc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -IInclude -I. -pthread
-Xlinker -lpthread -ldl -lutil -lm -export-dynamic -o pythons2.6
pythons.c
On 2008-01-14 22:23, Christian Heimes wrote:
The PEP is now available at http://www.python.org/dev/peps/pep-0370/.
The reference implementation is in svn, too:
svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/pep370
Thanks for the effort, Christian. Much appreciated.
Regarding the recent ~/bin vs.
On 2008-01-10 14:31, Eric Smith wrote:
(I'm posting to python-dev, because this isn't strictly 3.0 related.
Hopefully most people read it in addition to python-3000).
I'm working on backporting the changes I made for PEP 3101 (Advanced
String Formatting) to the trunk, in order to meet the
On 2008-01-07 14:57, Fred Drake wrote:
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote:
Next, we add a per-user site-packages directory to the standard
sys.path, and then we could get rid of most of the setuptools
import and sys.path hackery, making it a lot cleaner.
PYTHONPATH already
On 2008-01-07 17:24, Barry Warsaw wrote:
On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote:
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that issue, if we add a per-user site-packages
dir to sys.path
On 2007-11-29 11:52, Titus Brown wrote:
Hi all,
is there a good, or standard memory benchmarking system for Python?
pybench doesn't return significantly different results when Python 2.6
is compiled with pymalloc and without pymalloc. Thinking on it, I'm not
too surprised -- pybench
On 2007-11-23 23:12, Paul Moore wrote:
On 23/11/2007, Christian Heimes [EMAIL PROTECTED] wrote:
bsddb is automatically build by a build step. But you have to convert
the project files in build_win32 to VS 2008 first. Simply open the
solution file and let VS convert the projects.
VS 2008
On 2007-11-23 16:59, Christian Heimes wrote:
Paul Moore wrote:
_ssl
Christian has been making changes to allow this to build without Perl,
so I gave it a try. I used openssl 0.9.8g, which I extracted to the
build directory (I noticed afterwards that this is the same version as
in
On 2007-11-11 23:22, Martin v. Löwis wrote:
First, XML-RPC is not the only mechanism using XML over a network
connection. Second, you don't want to do this if you're dealing
with several 100 MB of data just because you want to figure
out the encoding.
That's my original claim/question: what
On 2007-11-11 14:51, Martin v. Löwis wrote:
A non-seekable stream is not all that uncommon in network processing.
Right. But what is the relationship to XML encoding autodetection?
It pops up whenever you need to detect the encoding of the
incoming XML data on the network connection, e.g. in
On 2007-11-11 18:56, Martin v. Löwis wrote:
First, XML-RPC is not the only mechanism using XML over a network
connection. Second, you don't want to do this if you're dealing
with several 100 MB of data just because you want to figure
out the encoding.
That's my original claim/question: what
On 2007-11-09 14:10, Walter Dörwald wrote:
Martin v. Löwis wrote:
Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
codecs to do the encoding. There's no need to create a magical
mystery codec to pick out which though.
So the code is good, if it is inside an XML parser, and
Martin v. Löwis wrote:
It makes working with XML data a lot easier: you simply don't have to
bother with the encoding of the XML data anymore and can just let the
codec figure out the details. The XML parser can then work directly
on the Unicode data.
Having the functionality indeed makes
Martin v. Löwis wrote:
Not really, but the codec has more control over what happens to
the stream, ie. it's easier to implement look-ahead in the codec
than to do the detection and then try to push the bytes back onto
the stream (which may or may not be possible depending on the
nature of the
On 2007-10-26 05:41, Barry Warsaw wrote:
On Oct 22, 2007, at 11:30 PM, [EMAIL PROTECTED] wrote:
It's not clear that any of these implementations is going to be
perfect.
Maybe none ever will be.
I would agree with this. You write a program and know you need to
implement some kind of
Nick Maclaren wrote:
Ah, the makefile. I don't think you use it create the Unicode database.
It's only good for generating the codecs (Lib/encodings)
Yes, but it DOES attempt to download the mappings, and is the ONLY
script which attempts to do so.
Of course it does. The
On 2007-06-19 14:40, Walter Dörwald wrote:
Georg Brandl wrote:
A minuscule nit: the rot13 codec has no library equivalent, so it won't be
supported anymore :)
Given that there are valid use cases for bytes-to-bytes translations,
and a common API for them would be nice, does it make sense to
Hi Mark,
+1 from me.
I think this is simply a bug introduced with the UCS4 patches in
Python 2.2.
unicodeobject.h already has this code:
#ifndef PY_UNICODE_TYPE
/* Windows has a usable wchar_t type (unless we're using UCS-4) */
# if defined(MS_WIN32) Py_UNICODE_SIZE == 2
# define
On 2007-05-21 12:30, Kristján Valur Jónsson wrote:
[Py_UNICODE being #defined as unsigned short on Windows]
I'd rather make it a platform-specific definition (for platform=Windows
API). Correct me if I'm wrong, but isn't wchar_t also available in VS
2003 (and even in VC6?). And doesn't it
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
PEP: 365
Title: Adding the pkg_resources module
I'm really surprised that there
On 2007-05-21 16:05, Phillip J. Eby wrote:
At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as
well. Feedback
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you provided doesn't really explain the concepts, reading
On 2007-05-21 22:48, Phillip J. Eby wrote:
At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP
On 2007-05-12 02:42, Andrew McNabb wrote:
On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote:
I wonder how we managed to survive all these years with
the existing consistent and concise definition of the
raw-unicode-escape codec ;-)
There are two options:
* no one really uses
On 2007-05-13 18:04, Martin v. Löwis wrote:
* without the Unicode escapes, the only way to put non-ASCII
code points into a raw Unicode string is via a source code encoding
of say UTF-8 or UTF-16, pretty much defeating the original
requirement of writing ASCII code only
That's no
On 2007-05-11 07:52, Martin v. Löwis wrote:
This is what prompted my question, actually: in Py3k, in the
str/unicode unification branch, r\u1234 changes meaning: before the
unification, this was an 8-bit string, where the \u was not special,
but now it is a unicode string, where \u *is*
On 2007-05-11 13:05, Thomas Heller wrote:
M.-A. Lemburg schrieb:
On 2007-05-11 07:52, Martin v. Löwis wrote:
This is what prompted my question, actually: in Py3k, in the
str/unicode unification branch, r\u1234 changes meaning: before the
unification, this was an 8-bit string, where the \u
On 2007-05-10 20:53, Paul Moore wrote:
On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I just discovered that, in all versions of Python as far back as I
have access to (2.0), \u escapes are interpreted inside raw
unicode strings. Thus:
[...]
Does anyone remember why it is done
On 2007-05-11 00:11, Guido van Rossum wrote:
On 5/10/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-05-10 20:53, Paul Moore wrote:
On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I just discovered that, in all versions of Python as far back as I
have access to (2.0), \u escapes
On 2007-05-04 19:51, Guido van Rossum wrote:
[-python-dev]
On 5/4/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 04 May 2007, M.-A. Lemburg wrote:
I also suggest making all bytes literals immutable to avoid running
into any issues like the above.
+1 from me.
Rather than
On 2007-05-05 18:11, Steven Bethard wrote:
On 5/5/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-05-04 19:51, Guido van Rossum wrote:
[-python-dev]
On 5/4/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 04 May 2007, M.-A. Lemburg wrote:
I also suggest making all bytes
Hi Walter,
if the bytes type does turn out to be a mutable type as suggested
in PEP 358, then please make sure that no code (C code in
particular), relies on the constantness of these byte objects.
This is especially important when it comes to codecs, since
the error callback logic would allow
On 2007-05-01 02:29, Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
Could you add a section that explains the side effects of
importing pkg_resources ?
The documentation of
On 2007-05-04 18:53, Georg Brandl wrote:
M.-A. Lemburg schrieb:
Hi Walter,
if the bytes type does turn out to be a mutable type as suggested
in PEP 358, then please make sure that no code (C code in
particular), relies on the constantness of these byte objects.
This is especially important
On 2007-03-23 19:18, Jason Orendorff wrote:
Scheme is adding Unicode support in an upcoming standard:
(DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html
I have two questions for the python-dev team about Python's Unicode
experiences. If it's convenient, please take a moment
On 2007-03-15 07:45, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
And yet, that incorrect behavior was clearly intended by the author(s)
of the code, test, and docstrings.
As it happens, Guido wrote that code (16 years ago) and the docstring (9
years ago), in the case of the posixpath
Hi Skip,
On 2007-03-12 03:01, [EMAIL PROTECTED] wrote:
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to
On 2007-02-12 16:19, Georg Brandl wrote:
Tim Delaney asked in particular:
Have you checked if [the existing uses of getattr, where getattr in
that scope is a function argument with default value the built-in
getattr] are intended to bring the getattr name into local scope
for fast lookup, or
On 2007-01-20 00:01, Brett Cannon wrote:
On 1/19/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-01-19 22:33, Brett Cannon wrote:
That's a typical error situation you get in __del__ methods at
the time the interpreter is shut down.
Yeah, but in this case this is at the end
On 2007-01-18 20:53, Brett Cannon wrote:
I have discovered an issue relating to func_globals for functions and
the deallocation of the module it is contained within. Let's say you
store a reference to the function encodings.search_function from the
'encodings' module (this came up in C code,
On 2007-01-03 01:42, Brett Cannon wrote:
On 1/2/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
+Open Issues
+===
+
+Consolidate dependent modules together into a single module or
package?
...
+Consolidate certain modules with similar themes together in a
package
On 2007-01-04 07:59, Neal Norwitz wrote:
The current schedule looks like it's shaping up to be:
Wed, Jan 24 for 2.5.1c1
Wed Jan 31 for 2.5.1
It would be great if you could comment on some of the bug reports
below. I think several already have patches/suggested fixes.
It's not clear to
On 2007-01-03 00:35, Barry Warsaw wrote:
On Jan 2, 2007, at 5:41 PM, M.-A. Lemburg wrote:
Note that as side-effect of this it becomes a lot harder to manipulate
PYTHONPATH to trick Python into loading a standard module from a
non-standard location, improving security and robustness
On 2007-01-02 01:02, brett.cannon wrote:
Author: brett.cannon
Date: Tue Jan 2 01:02:41 2007
New Revision: 53204
Added:
peps/trunk/pep-3108.txt (contents, props changed)
Modified:
peps/trunk/pep-.txt
Log:
Add PEP 3108: Standard Library Reorganization.
...
+Open Issues
On 2007-01-02 23:54, Brett Cannon wrote:
On 1/2/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-01-02 01:02, brett.cannon wrote:
Author: brett.cannon
Date: Tue Jan 2 01:02:41 2007
New Revision: 53204
Added:
peps/trunk/pep-3108.txt (contents, props changed)
Modified
On 2006-12-06 10:26, Fredrik Lundh wrote:
over at my work copy of the python language reference, Adrian Holovaty
asked about the exact semantics of the __str__ hook:
http://effbot.org/pyref/__str__
The return value must be a string object. Does this mean it can be a
*Unicode*
On 2006-12-06 10:46, M.-A. Lemburg wrote:
On 2006-12-06 10:26, Fredrik Lundh wrote:
over at my work copy of the python language reference, Adrian Holovaty
asked about the exact semantics of the __str__ hook:
http://effbot.org/pyref/__str__
The return value must be a string object
On 2006-12-06 10:56, Fredrik Lundh wrote:
M.-A. Lemburg wrote:
This was added to make the transition to all Unicode in 3k easier:
thanks for the clarification.
do you recall when this was added? 2.5?
Not really, only that it was definitely before 2.5.
--
Marc-Andre Lemburg
eGenix.com
Travis E. Oliphant wrote:
PEP: unassigned
Title: Adding data-type objects to the standard library
Attributes
kind -- returns the basic kind of the data-type. The basic kinds
601 - 700 of 989 matches
Mail list logo
