Dirkjan Ochtman wrote:
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
Two things:
* We need some form of documentation of how committers are expected
to
Paul Moore wrote:
2009/7/7 Ben Finney ben+pyt...@benfinney.id.au:
Paul Moore p.f.mo...@gmail.com writes:
In fact, the above strongly suggests to me that PEP 376 must NOT
follow setuptools conventions - otherwise, it will end up clashing
with the files setuptools is putting on my system.
I
Paul Moore wrote:
I know some people are writing to /etc to add their configuration file
on the system,
So a real-world example under linux would be:
setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
That is basically how the examples are shown at:
Paul Moore wrote:
2009/7/7 M.-A. Lemburg m...@egenix.com:
The PEP should take the chance to define not only the
directory, but also the complete set of files in there and
their format.
A typical setuptools dir looks like this:
dependency_links.txt
namespace_packages.txt
not-zip-safe
PKG
Brett Cannon wrote:
On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg m...@egenix.com wrote:
Dirkjan Ochtman wrote:
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though
Dirkjan Ochtman wrote:
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburgm...@egenix.com wrote:
Is there a standard notation for hg revisions that roundup could
detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
Hmm, no prefix or suffix ?
So we'll always have
James Y Knight wrote:
On Jul 21, 2009, at 7:38 PM, David Lyon wrote:
When I go into python on ubuntu I see there is /usr/local/pythonX.X/lib/
site-packages and I'm wondering why the hubba setuptools/distutils
doesn't put packages there by default. That would solve a lot of
problems.
Just
James Y Knight wrote:
On Jul 22, 2009, at 4:49 AM, M.-A. Lemburg wrote:
Debian has a long history of doing this different, so it's
not much of a surprise. They also apply such changes to
Python packages.
However, all of this is non-standard and will cause problems
with tools that rely
David Lyon wrote:
On Wed, 22 Jul 2009 23:22:56 +0200, M.-A. Lemburg m...@egenix.com wrote:
Maybe I've misunderstood some important detail, but how will
their change help with anything other than making their
distribution a non-standard Python installation ?
The Debian/ubuntu distribution
Martin v. Löwis wrote:
These files are in 8859-1 encoding (names in comments, at least):
http://svn.python.org/view/python/trunk/Lib/encodings/punycode.py
http://svn.python.org/view/python/trunk/Lib/test/test_csv.py
http://svn.python.org/view/python/trunk/Tools/i18n/msgfmt.py
Neil Hodgson wrote:
Glenn Linderman:
and perhaps other things (and
are there new Unicode control characters that could be used for line
endings?),
Unicode includes Line Separator U+2028 and Paragraph Separator
U+2029 but they are rarely supported and very rarely used. They are a
pain
Nick Coghlan wrote:
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.
Actually, no. It has been designed from the start
M.-A. Lemburg wrote:
Nick Coghlan wrote:
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.
Actually, no. It has been
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
What I don't understand is why the io layer tries to reinvent
the wheel here instead of just using the codec's .readline()
method - which *does* use .splitlines() and has full support
for all Unicode line break characters
Chris Withers wrote:
Hi All,
Would anyone object if I removed the deletion of of
sys.setdefaultencoding in site.py?
I'm guessing yes! so thought I'd state my reasons now:
This deletion appears to be pretty flimsy; reload(sys) and you have it
back. Which is lucky, because I need it
Chris Withers wrote:
M.-A. Lemburg wrote:
Let's look at this from another angle: sys.setdefaultencoding()
is only made available for use in site.py.
...see this:
http://mail.python.org/pipermail/python-dev/2009-August/091391.html
I would like to use sitecustomize.py for all the very
Kristján Valur Jónsson wrote:
I noticed something (in 2.5) yesterday, which may be a feature, but is more
likely a bug.
In tokenizer.c, tok-encoding is allocated using PyMem_MALLOC().
However, this then gets handed to a node-r_str in parsetok.c, and then
released in node.c using
Mark Shannon wrote:
Michael Foord wrote:
Hello all,
A paper (well, presentation) has been published highlighting security
problems with the hashing
algorithm (exploiting collisions) in many programming languages Python
included:
Frank Sievertsen wrote:
Hello,
I'd still prefer to see a randomized hash()-function (at least for 3.3).
But to protect against the attacks it would be sufficient to use
randomization for collision resolution in dicts (and sets).
What if we use a second (randomized) hash-function in case
Nick Coghlan wrote:
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
Add an argument to change the result type
-
There should also be a description of the set a boolean flag to
request high precision output approach.
You mean something like:
Nick Coghlan wrote:
The reason Python 2's implicit str-unicode conversions are so
problematic isn't just because they're implicit: it's because they
effectively assume *latin-1* as the encoding on the 8-bit str side.
The implicit conversion in Python2 only works with ASCII content,
pretty much
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my frozendict proposition doesn't convert
Steven D'Aprano wrote:
M.-A. Lemburg wrote:
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my
Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
This is in the context of changing the name of the 'Scripts' directory
on windows to 'bin'. Éric brings up the point (explained more below)
that if we make this change, packages made/installed the new packaging
VanL wrote:
As this has been brought up a couple times in this subthread, I figured that
I would lay out the
rationale here.
There are two proposals on the table: 1) Regularize the install layout, and
2) move the python
binary to the binaries directory. This email will deal with the
Victor Stinner wrote:
You seem to have missed the episode where I explained that caching the last
value in order to avoid going backwards doesn't work -- at least not if the
cached value is internal to the API implementation.
Yes, and I can't find it by briefly searching my mail. I haven't
Victor Stinner wrote:
Hi,
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
The implementation of the PEP can be found in this issue:
http://bugs.python.org/issue14428
I post a simplified
Just to add my 2 cents to this discussion as someone who's worked
with mxDateTime for almost 15 years.
I think we all agree that users of an application want to input
date/time data using their local time (which may very well not be
the timezone of the system running the application). On output
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-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-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-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-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-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-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-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-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-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-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-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-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
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-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
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-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-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-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
Duesseldorf: HRB 46611
On 2008-05-27 12:10, M.-A. Lemburg wrote:
On 2008-05-26 23:34, Christian Heimes wrote:
M.-A. Lemburg schrieb:
Isn't that an awefuly confusing approach ?
Wouldn't it be better to keep PyString APIs and definitions in
stringobject.c|h
and only add a new bytesobject.h
On 2008-05-28 14:29, Paul Moore wrote:
On 28/05/2008, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
I care, but I struggle
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-28 19:08, Bill Janssen wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
I share your concern. Seems to me that perhaps (not sure, but
perhaps) the rush to
On 2008-05-28 22:47, Gregory P. Smith wrote:
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I'm beginning to wonder whether I'm the only one who cares about
the Python 2.x branch not getting cluttered up with artifacts caused
by a broken forward merge strategy.
How can
Registered at Amtsgericht Duesseldorf: HRB 46611
On 2008-05-29 17:45, Christian Heimes wrote:
M.-A. Lemburg schrieb:
Well, first of all, it is a change in the C API:
APIs have different names now, they live in different files,
the Python documentation doesn't apply anymore, books have
On 2008-06-02 01:30, Gregory P. Smith wrote:
On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Sorry, I probably wasn't clear enough:
Why can't we have both PyString *and* PyBytes exposed as C
APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
On 2008-06-03 01:09, Guido van Rossum wrote:
I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
(as both what the linker sees and what the human reads in the source
code) and the 3.0 code use PyBytes for the
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
...
Should we read this as a
On 2008-06-06 13:27, Georg Brandl wrote:
Hi,
PEP 361 lists the following modules for possible inclusion in 2.6 (next
to pyprocessing, which is now accepted):
- winerror
http://python.org/sf/1505257
(Owner: MAL)
This patch has been marked as rejected, so I'll remove the entry from
the PEP.
On 2008-06-09 07:20, Gregory P. Smith wrote:
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum [EMAIL PROTECTED]
wrote:
I will freely admit that I haven't followed this thread
On 2008-06-11 05:42, Gregory P. Smith wrote:
On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-06-09 07:20, Gregory P. Smith wrote:
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon, Jun
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the release
blocker issues, but nature intervened. A bunch of severe thunderstorms
knock out my 'net access until this morning.
I'll try to find some time during the day to look at the RB
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net access until this morning
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64
On 2008-06-13 11:32, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type
On 2008-06-15 16:47, Georg Brandl wrote:
Thomas Lee schrieb:
Georg Brandl wrote:
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
Ah of course. Looks like I should just avoid optimizations of
Name(True) and Name(False) all together. That's a shame!
We
I think the discussion is going in the wrong direction:
The choice between UCS2 and UCS4 builds is really only meant
to enhance the possibility to interface to native OS or
application APIs, e.g. Windows LIBC and Java use UTF-16, glibc
on Unix uses UCS4.
The problem of slicing Unicode objects
On 2008-07-03 15:21, Jeroen Ruigrok van der Werven wrote:
-On [20080703 15:00], M.-A. Lemburg ([EMAIL PROTECTED]) wrote:
Unicode if full of combining code points - if you break such a sequence,
the output will be just as wrong; regardless of UCS2 vs. UCS4.
In my opinion you are confusing two
On 2008-07-03 19:21, Adam Olsen wrote:
On Thu, Jul 3, 2008 at 7:57 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-07-03 15:21, Jeroen Ruigrok van der Werven wrote:
-On [20080703 15:00], M.-A. Lemburg ([EMAIL PROTECTED]) wrote:
Unicode if full of combining code points - if you break
On 2008-07-03 19:35, Jeroen Ruigrok van der Werven wrote:
-On [20080703 19:21], Adam Olsen ([EMAIL PROTECTED]) wrote:
On Thu, Jul 3, 2008 at 7:57 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Please remember that lone surrogate pair code points are perfectly
valid Unicode code points
On 2008-07-03 19:44, Terry Reedy wrote:
The premise of this thread seems to be that the majority should suffer
for the benefit of a few. That is not Python's philosophy.
In reality, most Unixes ship with UCS4 builds of Python. Windows
and Mac OS X ship with UCS2 builds. Still, anyone is free
On 2008-07-03 21:59, Steve Holden wrote:
M.-A. Lemburg wrote:
On 2008-07-03 19:44, Terry Reedy wrote:
The premise of this thread seems to be that the majority should
suffer for the benefit of a few. That is not Python's philosophy.
In reality, most Unixes ship with UCS4 builds of Python
On 2008-07-16 02:20, Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney [EMAIL PROTECTED] wrote:
Significant updates include removing all reference to the
(already-resolved) new-style class issue, adding footnotes and
references, and a Rationale summary of discussion on both sides
On 2008-07-16 10:14, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
On 2008-07-16 10:14, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent
On 2008-07-16 15:12, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
Note that PEP 4 targets deprecating use of whole modules, not
single APIs, or - like in your case - more or less the complete
existing API of a module
On 2008-07-18 21:35, Charles Hixson wrote:
Invariably, when someone goes and removes a module, someone else is
going to complain, but I used feature X, not having feature X will
break my code. We, as maintainers can then say, if you cared,
maintain it. But I'm not sure that is the greatest
On 2008-07-20 22:45, Victor Stinner wrote:
Le Saturday 19 July 2008 21:52:09 A.M. Kuchling, vous avez écrit :
Excellent work! Another fruitful area for fuzzing might be the
miniature virtual machine used by the re module. It's possible to
import _sre and call the compile() function directly
On 2008-08-01 15:06, Barry Scott wrote:
I cannot see how I implement decode() for bytes objects using the C API
for PyCXX library,
I'd assuming that I should find a PyBytes_Decode function but cannot
find it
in beta 2.
What is the preferred way to do this?
PyUnicode_FromEncodedObject()
On 2008-08-06 18:55, Antoine Pitrou wrote:
Martin v. Löwis martin at v.loewis.de writes:
URLs are just not made for non-ASCII characters.
Perhaps they are not, but every non-English wiki (just to take a simple, generic
example) potentially contains non-ASCII URLs.
e.g.
First, I'd like to know why this discussion is happening on
the committers list.
Python-dev is the right list for these things. I've adjusted the
CC accordingly.
On 2008-08-12 20:44, Martin v. Löwis wrote:
I am planning to offer a single file patch for 2.3 and 2.4. As far as
one more 2.5
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries are provided - thus,
On 2008-08-13 04:57, Guido van Rossum wrote:
And there's a reason for this slow uptake of Python 2.5: as more
and more servers run 64-bit OSes, the Py_ssize_t changes cause
serious trouble with Python C extensions that were not updated
by their authors.
I'm not sure what that has to do with
On 2008-08-13 15:20, Steve Holden wrote:
M.-A. Lemburg wrote:
Perhaps we should just document the maintenance of Python releases
more clearly and also plan for a final bug fix release 3 years after
the initial branch release. That way developers and users can also
adjust their plans accordingly
401 - 500 of 989 matches
Mail list logo
