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
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
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,
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
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
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
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
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
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:
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:
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
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
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:
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
Nick Coghlan wrote:
[PEP]
Function-like macros (in particular, field access macros) remain
available to applications, but get replaced by function calls
(unless their definition only refers to features of the ABI, such
as the various _Check macros)
[MAL]
Including Py_INCREF()/Py_DECREF() ?
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Now, with the PEP, I have a feeling that the Python C-API
will in effect be limited to what's in the PEP's idea of
a usable ABI and open up the non-inluded public C-APIs
to the same rate of change as the private APIs.
Not really - before this PEP
Martin v. Löwis wrote:
Now, with the PEP, I have a feeling that the Python C-API
will in effect be limited to what's in the PEP's idea of
a usable ABI and open up the non-inluded public C-APIs
to the same rate of change as the private APIs.
That's certainly not the plan. Instead, the plan
Martin v. Löwis wrote:
Thomas Wouters reminded me of a long-standing idea; I finally
found the time to write it down.
Please comment!
...
Up until this PEP proposal, we had a very simple scheme for
the Python C-API: all documented functions and variables with
a Py prefix were part of the
Martin v. Löwis wrote:
The error handler for undoing this operation (ie. when converting
a Unicode string to some other encoding) should probably use the
same name based on symmetry and the fact that the escaping
scheme is meant to be used for enabling round-trip safety.
Could you please
Martin v. Löwis wrote:
The name utf8b suggested in the PEP is not in line with the codec
design
Where is that design documented, and how exactly violates the name
the design (chapter and verse, please).
Martin, I designed the whole Python codec machinery, so even if
this is not explicitly
Martin v. Löwis wrote:
The name utf8b suggested in the PEP is not in line with the codec
design
Where is that design documented, and how exactly violates the name
the design (chapter and verse, please).
Martin, I designed the whole Python codec machinery
Not true. PEP 293 was written and
On 2009-05-03 19:39, Martin v. Löwis wrote:
If the error handler is supposed to be used for codecs other than utf-8,
perhaps it should renamed something more generic, e.g. surrogate-escape?
Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
it's an algorithm based on
Martin v. Löwis wrote:
I have three substantive comments. First, although consequences for
Python 3 byte interfaces (ie, none) are explicitly stated, as far as
I can see this PEP could apply to Python 2 as well. I don't think
it's intended that way. Either way, I think you should clarify
On 2009-04-22 22:06, Walter Dörwald wrote:
Martin v. Löwis wrote:
correct - corrected
Thanks, fixed.
To convert non-decodable bytes, a new error handler python-escape is
introduced, which decodes non-decodable bytes using into a private-use
character U+F01xx, which is believed to not
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way
On 2009-04-15 16:44, P.J. Eby wrote:
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that
lives in
site-packages into smaller distribution
On 2009-04-15 19:59, P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK
On 2009-04-15 21:22, P.J. Eby wrote:
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being the common use case. I
expect
On 2009-04-07 19:46, P.J. Eby wrote:
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages
On 2009-04-07 18:19, Guido van Rossum wrote:
On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-06 15:21, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following
On 2009-04-14 18:27, P.J. Eby wrote:
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another
On 2009-04-06 15:21, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
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
[Resent due to a python.org mail server problem]
On 2009-04-03 22:07, Martin v. Löwis wrote:
I'd like to extend the proposal to Python 2.7 and later.
I don't object, but I also don't want to propose this, so
I added it to the discussion.
My (and perhaps other people's) concern is that 2.7
On 2009-04-03 02:44, P.J. Eby wrote:
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
Alternative Approach:
-
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1) check ?
One of the namespace
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1)
check ?
Again - this wouldn't be O(1). More importantly, it breaks
On 2009-04-03 18:06, Thomas Wouters wrote:
On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's
the
speed of the bytecode dispatcher (and it doesn't
401 - 500 of 989 matches
Mail list logo
