On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7 and later.
Please comment.
Regards,
Martin
Specification
=
Rather than using an imperative
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete
Should this
On 2009-03-27 13:58, David Cournapeau wrote:
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg m...@egenix.com wrote:
I think that esp. the bdist_* commands help developers a lot by
removing the need to know how to build e.g. RPMs or Windows
installers and let distutils deal with it.
I think
On 2009-03-27 15:00, Ronald Oussoren wrote:
On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality
On 2009-03-27 17:01, Eric Smith wrote:
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed distributions,
On 2009-03-27 17:19, P.J. Eby wrote:
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under three years now. Here's where you
quoted the email
On 2009-03-27 20:56, Guido van Rossum wrote:
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith e...@trueblade.com wrote:
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try
On 2009-03-27 21:49, gl...@divmod.com wrote:
On 07:59 pm, fdr...@acm.org wrote:
I'm actually in favor of removing the bdist_* from the standard
library, and allowing 3rd-party tools to implement whatever they need
for the distros. But I don't think what you're presenting there
supports it.
On 2009-03-27 20:24, s...@pobox.com wrote:
mal Zip files are great for shipping packages to the end-user, but
mal there's no need to keep them zipped once they get there.
I thought one of the arguments for zip files was a performance increase
(reduced stat(2) calls, etc). I may
On 2009-03-24 23:47, Martin v. Löwis wrote:
An installer for a pure-python package that made no attempt
to bundle dependencies might be nice, but I don't quite see how that
falls outside the scope of distutils/setuptools/etc. In other words, I
don't see why the installer can't bootstrap the
On 2009-02-16 17:54, Tarek Ziadé wrote:
2009/2/9 M.-A. Lemburg m...@egenix.com:
On 2009-02-08 11:15, Tarek Ziadé wrote:
Hello
To avoid confusion, as suggested by Akira who works on cleaning the
Distutils pages on the python.org website,
I would like to move http://svn.python.org/view
On 2009-02-16 18:50, Daniel (ajax) Diniz wrote:
Hi,
I've marked some issues (25 now) to close, mostly because:
- there was no reply from OP, nor a clear justification for the issue;
- there are messages explaining why the issue is invalid;
- the OSes/versions of the report suggest the issue
On 2009-02-08 11:15, Tarek Ziadé wrote:
Hello
To avoid confusion, as suggested by Akira who works on cleaning the
Distutils pages on the python.org website,
I would like to move http://svn.python.org/view/distutils/trunk into a
branch and add a README.txt in an empty trunk
to explain the
On 2009-02-01 19:44, Reto Schüttel wrote:
Hi
While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled
over a
strange locale-related problem on OS X. PyEphem is a library which can do
astronomical computations like tracking the position of stars, planets and
earth satellites
On 2009-01-30 11:40, Antoine Pitrou wrote:
Aahz aahz at pythoncraft.com writes:
There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
You're probably right that what Raymond wants to is best not done for
3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
On 2009-01-29 01:59, Stephen J. Turnbull wrote:
I think there is definitely something to the notion that the 3.x
vs. 3.0.y distinction should signal something, and I personally like
MAL's suggestion that 3.0.x should be marked some sort of beta in
perpetuity, or at least until 3.1 is ready to
On 2009-01-27 22:19, Raymond Hettinger wrote:
From: Martin v. Löwis mar...@v.loewis.de
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
I think it should be released earlier and completely supplant 3.0
before
On 2009-01-20 00:56, Raymond Hettinger wrote:
Why does numbers.py say:
# Copyright 2007 Google, Inc. All Rights Reserved.
# Licensed to PSF under a Contributor Agreement.
Because that's where that file originated, I guess. This is part
of what you have to do for things that are
On 2009-01-20 11:02, Michael Foord wrote:
M.-A. Lemburg wrote:
[snip...]
Does the copyright concept even apply to an
abstract base class (I thought APIs were not
subject to copyright, just like database layouts
and language definitions)?
It applies to the written program text. You
On 2009-01-20 16:54, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
On 2009-01-20 11:02, Michael Foord wrote:
Mere collections of facts are not copyrightable as they are not
creative (the basis of copyright)
That's incorrect in the U.S.; what is copyrightable is an *original
On 2009-01-08 01:01, Collin Winter wrote:
On Wed, Jan 7, 2009 at 2:35 PM, Brett Cannon br...@python.org wrote:
On Wed, Jan 7, 2009 at 10:57, M.-A. Lemburg m...@egenix.com wrote:
[SNIP]
BTW: The _codecsmodule.c file is a 4 spaces indent file as well (just
like all Unicode support source files
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
M.-A. Lemburg
Sent: 8. janúar 2009 09:49
To: Collin Winter
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] Fixing incorrect
On 2009-01-07 16:34, Guido van Rossum wrote:
Sounds like yet another remnant of the old philosophy, which indeed
supported encode and decode operations on both string types. :-(
No, that's something I explicitly readded to Python 3k, since the
codecs interface is independent of the input and
On 2009-01-07 19:32, Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
No, that's something I explicitly readded to Python 3k, since the
codecs interface is independent of the input and output types (the
codecs decide which combinations to support).
But why would the utf8
On 2009-01-05 23:17, Mark Hammond wrote:
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
Although ironically, assertions have been disabled in debug builds
to debug the MS CRT,
only Python ;-)
Kristj'an
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
M.-A. Lemburg
Sent: 6. janúar 2009 13:23
To: mhamm...@skippinet.com.au
Cc: python
On 2009-01-03 04:15, Adam Olsen wrote:
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-01-02 08:26, Adam Olsen wrote:
Python's malloc wrappers are pretty messy. Of your examples, only
unicode-str isn't obvious what the result is, as the rest are local
On 2009-01-02 08:26, Adam Olsen wrote:
On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen rha...@gmail.com wrote:
..
As C++ has more specific ways of allocating memory, they impose this
restriction to annoy
On 2008-12-20 23:16, Martin v. Löwis wrote:
I will try next week to see if I can come up with a smaller,
submittable example. Thanks.
These long exit times are usually caused by the garbage collection
of objects. This can be a very time consuming task.
I doubt that. The long exit times are
On 2008-12-22 19:13, Mike Coleman wrote:
On Mon, Dec 22, 2008 at 6:20 AM, M.-A. Lemburg m...@egenix.com wrote:
BTW: Rather than using a huge in-memory dict, I'd suggest to either
use an on-disk dictionary such as the ones found in mxBeeBase or
a database.
I really want this to work
On 2008-12-20 17:57, Mike Coleman wrote:
On Sat, Dec 20, 2008 at 4:02 AM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
Can you distill the program into something reproducible?
Maybe with something slightly less than 45Gb but still exhibiting some
degradation of exit performance?
I
On 2008-12-20 21:20, Leif Walsh wrote:
On Sat, Dec 20, 2008 at 3:04 PM, M.-A. Lemburg m...@egenix.com wrote:
These long exit times are usually caused by the garbage collection
of objects. This can be a very time consuming task.
In that case, the question would be why is the interpreter
On 2008-12-14 21:43, Martin v. Löwis wrote:
Personally, I think the indentation of, at least,
Objects/unicodeobject.c should be fixed. This file has become so
mixed-up with tab and space indents that I have no-idea what to use
when I edit it. Just to give an idea how messy it is, they are 5214
On 2008-12-10 21:05, Adam Olsen wrote:
On Wed, Dec 10, 2008 at 12:22 PM, BJörn Lindqvist [EMAIL PROTECTED] wrote:
One thing i think it would be useful for in the real world is for
unittesting extension modules. You cant profitably write unit tests
for segfaults because that breaks the test
On 2008-12-09 09:41, Anders J. Munch wrote:
On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy [EMAIL PROTECTED] wrote:
try:
files = os.listdir(somedir, errors = strict)
except OSError as e:
log(verbose error message that includes somedir and e)
files = os.listdir(somedir)
Instead of a codecs
On 2008-12-06 01:48, Nick Coghlan wrote:
You can't display a non-decodable filename to the user, hence the user
will have no idea what they're working on. Non-filesystem related apps
have no business trying to deal with insane filenames.
This is not entirely true: OSes, shells, and
On 2008-12-08 19:26, Guido van Rossum wrote:
On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy [EMAIL PROTECTED] wrote:
Here is a possible use case: I want filenames as 3.0 strings and I
anticipate no problems at present but, as you say above, something might
happen years in the future. I am using
On 2008-12-08 21:45, Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Such application specific error handlers could then also apply
whatever fancy round-trip safe encoding of non-decodable bytes
to Unicode escapes, private code points, etc. as seen fit by the
application.
I'd
On 2008-12-08 22:32, Adam Olsen wrote:
On Mon, Dec 8, 2008 at 2:01 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-12-08 21:45, Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Such application specific error handlers could then also apply
whatever fancy round-trip safe
On 2008-12-08 22:39, Victor Stinner wrote:
('strict', 'ignore', 'replace', 'xmlcharrefreplace')
replace (or xmlcharrefreplace) is just useless because you will not be unable
to open or rename the file... You just know that there is a strange file in
the directory.
Right, but that's
On 2008-11-28 00:15, Christian Heimes wrote:
Martin v. Löwis wrote:
All, and not to start flames, but I still do not understand why
applink.c isn't included in python's main (conditionally) instead of
expecting users, many of them novices, to do the build. ???
One reason is that I don't
On 2008-11-16 02:14, Nick Coghlan wrote:
M.-A. Lemburg wrote:
Guess I could add a .weeks attribute to mxDateTime, but no one ever
asked for that so far.
Given that there are at least 3 different ways to define the number of
weeks between two dates, it may be something best left
On 2008-11-14 23:59, Victor Stinner wrote:
Hi,
There are some interresting tickets about the datetime module:
#1673409: datetime module missing some important methods
#1083: Confusing error message when dividing timedelta using /
#2706: datetime: define division timedelta/timedelta
#4291:
On 2008-10-24 09:53, J. Sievers wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
[snip]
BTW: I hope you did not use pybench to get profiles of the opcodes.
That would most certainly result in good results for pybench, but
less good ones for general applications such as Django or Zope/Plone
On 2008-10-23 09:08, J. Sievers wrote:
a) It's fairly easy to implement different types of dispatch, simply by
changing a few macros (and while I haven't done this, it shouldn't be a
problem to add some switch dispatch #ifdefs for non-GCC platforms).
In particular, direct threaded code leads
On 2008-10-23 15:19, David Ripton wrote:
On 2008.10.23 12:02:12 +0200, M.-A. Lemburg wrote:
BTW: I hope you did not use pybench to get profiles of the opcodes.
That would most certainly result in good results for pybench, but
less good ones for general applications such as Django or Zope/Plone
On 2008-10-22 14:16, J. Sievers wrote:
Hi,
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made
it fairly straightforward to add direct threaded code and superinstructions
for
the various permutations of LOAD_CONST, LOAD_FAST, and most of the
two-argument
VM
On 2008-10-07 22:18, Fred Drake wrote:
On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote:
b) I would propose that the notion of a default encoding is entirely
eliminated from Python, along with sys.(get|set)defaultencoding
+1
As already mentioned in my reply to Viktor: +1. It's not
On 2008-10-01 09:54, Ulrich Eckhardt wrote:
On Tuesday 30 September 2008, M.-A. Lemburg wrote:
On 2008-09-30 08:00, Martin v. Löwis wrote:
Change the default file system encoding to store bytes in Unicode is
like introducing a new Python type: fake Unicode for filename hacks.
Exactly. Seems
On 2008-09-30 08:00, Martin v. Löwis wrote:
Change the default file system encoding to store bytes in Unicode is like
introducing a new Python type: fake Unicode for filename hacks.
Exactly. Seems like the best solution to me, despite your polemics.
Not a bad idea... have os.listdir()
On 2008-09-30 18:46, Guido van Rossum wrote:
On Tue, Sep 30, 2008 at 8:20 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
In the end, I think it's better not to be clever and just return
the filenames that cannot be decoded as bytes objects in os.listdir().
Unfortunately that's going to break
On 2008-09-29 12:50, Ulrich Eckhardt wrote:
On Sunday 28 September 2008, Gregory P. Smith wrote:
broken systems will always exist. Code to deal with them must be
possible to write in python 3.0.
since any given path (not just fs) can have its own encoding it makes
the most sense to me to
On 2008-09-03 04:12, Greg Ewing wrote:
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally
undoing an explicit change made by the user ?
Is that really much of an issue? If the PATH contains an
entry corresponding to the Python installation that's
being
On 2008-09-03 10:15, Cesare Di Mauro wrote:
On 03 sep 2008 at 00:50:13, M.-A. Lemburg [EMAIL PROTECTED] wrote:
There already is a menu entry that starts the Python interpreter
on Windows, so why not use that ?
Because i need to start Python from folders which have
files that define
The download page doesn't list any Windows installer for 2.6b3:
http://www.python.org/download/releases/2.6/
I suppose this is due to Martin building the installers and him not
be available at the moment.
Since Python on Windows will likely only get very few beta testers
without a Windows
On 2008-09-02 23:14, Terry Reedy wrote:
Tarek Ziadé wrote:
So I don't see any good reason (besides the technical complexity)
Unless and until someone is able and willing to deal with the technical
complexity, that would seem to be a sufficient reason.
to [not, I presume] add it to the
On 2008-08-28 21:31, Michael Foord wrote:
Hello all,
The documentation for __hash__ seems to be outdated. I'm happy to submit
a patch, so long as I am not misunderstanding something.
http://docs.python.org/dev/reference/datamodel.html#object.__hash__
The documentation states:
If a
On 2008-08-29 13:03, Matt Giuca wrote:
Being hashable is a different from being usable as dictionary key.
Dictionaries perform the lookup based on the hash value, but will
then have to check for hash collisions based on an equal comparison.
If an object does not define an equal comparison,
On 2008-08-27 09:54, Greg Ewing wrote:
Do you have a real-life example of this where multiple
inheritance is actually used?
A non-contrived example or two would be a good thing to
have in tutorials etc. where super() is discussed. It
would help to convey the kinds of situations in which
On 2008-08-24 21:04, Antoine Pitrou wrote:
TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms
+48.2%
Whoa, that's a big slowdown. I wonder if it's consistent?
Yes, I can definitely reproduce it.
That's a huge slow-down compared to 2.5.
Are there any obvious reasons
On 2008-08-22 03:25, Guido van Rossum wrote:
On Thu, Aug 21, 2008 at 2:26 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-08-21 22:35, Guido van Rossum wrote:
I was just paid a visit by my Google colleague Mark Davis, co-founder
of the Unicode project and the president of the Unicode
On 2008-08-25 19:34, Barry Warsaw wrote:
On Aug 21, 2008, at 6:30 PM, Terry Reedy wrote:
http://www.unicode.org/versions/Unicode5.1.0/
Unicode 5.1.0 contains over 100,000 characters, and provides
significant additions and improvements... to existing features,
including new files and
On 2008-08-21 22:35, Guido van Rossum wrote:
I was just paid a visit by my Google colleague Mark Davis, co-founder
of the Unicode project and the president of the Unicode Consortium. He
would like to see improved Unicode support for Python. (Well duh. :-)
On his list of top priorities are:
1.
On 2008-08-14 08:43, Martin v. Löwis wrote:
For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Since we don't have a fixed release cycle, making the 2.(n-1)
maintenance time frame depend
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
On 2008-08-13 22:32, Martin v. Löwis wrote:
It's difficult to use such download numbers as hint for the number
of deployed installations. 2.4.5 was not released as binary, so
interested parties had to compile that version by themselves and
those installations don't show up in your statistics.
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-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.
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-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-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-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-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
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-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
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-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-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-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-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-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-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-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
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
501 - 600 of 989 matches
Mail list logo
