On 29.06.2020 11:57, Victor Stinner wrote:
> Le dim. 28 juin 2020 à 11:22, M.-A. Lemburg a écrit :
>> as you may remember, I wasn't happy with the deprecations of the
>> APIs in PEP 393, since there are no C API alternatives for
>> the encoding APIs deprecated in t
On 28.06.2020 16:24, Inada Naoki wrote:
> Hi, Lamburg.
>
> Thank you for quick response.
>
>>
>> We can't just remove access to one half of a codec (the decoding
>> part) without at least providing an alternative for C extensions
>> to use.
>>
>> Py_UNICODE can be removed from the API, but only i
On 30.06.2020 15:17, Victor Stinner wrote:
> Le mar. 30 juin 2020 à 13:53, M.-A. Lemburg a écrit :
>>> I would prefer to analyze the list on a case by case basis. I don't
>>> think that it's useful to expose every single encoding supported by
>>> Python a
Hi Inada-san,
I am currently too busy with EuroPython to participate in longer
discussions. FWIW: I intend to continue after EuroPython.
In any case, thanks for writing up the PEP. Could you please add my
points about:
- the fact that the encode APIs encoding from a Unicode buffer
to a bytes o
Steering
> Council discussion.
> Would you like to review the PEP before it?
>
> Regards,
>
>
> On Thu, Jul 9, 2020 at 8:19 AM Inada Naoki wrote:
>>
>> On Thu, Jul 9, 2020 at 5:46 AM M.-A. Lemburg wrote:
>>> - the fact that the encode APIs encoding
Thank you, Larry and the whole release team, for putting so much
work into this !
On 01.10.2020 19:49, Larry Hastings wrote:
>
> At last! Python 3.5 has now officially reached its end-of-life. Since there
> have been no checkins or PRs since I tagged 3.5.10, 3.5.10 will stand as the
> final rel
Hi Pablo,
thanks for pointing this out.
Would it be possible to get the data for older runs back, so that
it's easier to find the changes which caused the slowdown ?
Going to the timeline, it seems that the system only has data
for Oct 14 (today):
https://speed.python.org/timeline/#/?exe=12&ben
gt; automated and it didn't run in a long time :(
Make sense.
Would it be possible rerun the tests with the current
setup for say the last 1000 revisions or perhaps a subset of these
(e.g. every 10th revision) to try to binary search for the revision which
introduced the change ?
>
On 14.10.2020 16:14, Antoine Pitrou wrote:
> Le 14/10/2020 à 15:16, Pablo Galindo Salgado a écrit :
>> Hi!
>>
>> I have updated the branch benchmarks in the pyperformance server and now
>> they include 3.9. There are
>> some benchmarks that are faster but on the other hand some benchmarks
>> are su
On 14.10.2020 17:59, Antoine Pitrou wrote:
>
> Le 14/10/2020 à 17:25, M.-A. Lemburg a écrit :
>>
>> Well, there's a trend here:
>>
>> [...]
>>
>> Those two benchmarks were somewhat faster in Py3.7 and got slower in 3.8
>> and then again in 3.
On 15.10.2020 15:50, Victor Stinner wrote:
> Le mer. 14 oct. 2020 à 17:59, Antoine Pitrou a écrit :
>> unpack-sequence is a micro-benchmark. (...)
>
> I suggest removing it.
>
> I removed other similar micro-benchmarks from pyperformance in the
> past, since they can easily be misunderstood and
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
On 2009-02-16 17:54, Tarek Ziadé wrote:
> 2009/2/9 M.-A. Lemburg :
>> 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,
>&g
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 iss
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 bootstra
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 t
On 2009-03-27 13:58, David Cournapeau wrote:
> On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg 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
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)
>&g
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
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 distribution
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
On 2009-03-27 20:56, Guido van Rossum wrote:
> On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith wrote:
>> M.-A. Lemburg wrote:
>>> On 2009-03-27 04:19, Guido van Rossum wrote:
>>>> - keep distutils, but start deprecating certain higher-level
>>>> functionali
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
>> sup
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 ma
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 impera
On 2009-04-03 18:06, Thomas Wouters wrote:
> On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou wrote:
>
>> Thomas Wouters 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 measure it particu
On 2009-04-06 15:21, Jesse Noller wrote:
> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg 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 ex
[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 th
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 name
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
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
On 2009-04-07 18:19, Guido van Rossum wrote:
> On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg wrote:
>> On 2009-04-06 15:21, Jesse Noller wrote:
>>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
>>>> On 2009-04-02 17:32, Martin v. Löwis wrote:
>>
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 argum
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 PE
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
>&g
On 2009-04-15 19:38, James Y Knight wrote:
>
> On Apr 15, 2009, at 12:15 PM, 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.
&
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 s
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
>>
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
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 bas
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 c
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 expl
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 29
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> py> b'\xed\xa0\x80'.decode("utf-8","surrogates")
>> '\ud800'
>
> The point is, "surrogates" does not mean anything intuitive for an /error
> handler/. You seem to be the only one who finds this name explicit enough,
> perhaps because
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
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 o
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 p
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, t
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]
> Includ
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 :
>> Paul Moore 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 think the argument for a separa
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I suggest that we also run a version of that redirection filter to remap
>>> the old svn.python.org links in addition to making them accessible
>>> through hg.python.org as Dirkjan proposed.
>> Not sure what links you are talking about, but we also n
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:
>>
>> http://docs.
Paul Moore wrote:
> 2009/7/7 M.-A. Lemburg :
>> 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.
Brett Cannon wrote:
> On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg 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
&g
Dirkjan Ochtman wrote:
> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg 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&#x
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.
>
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
David Lyon wrote:
> On Wed, 22 Jul 2009 23:22:56 +0200, "M.-A. Lemburg" 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 inst
"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 a
Nick Coghlan wrote:
> Antoine Pitrou wrote:
>> M.-A. Lemburg 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.
>>
&
M.-A. Lemburg wrote:
> Nick Coghlan wrote:
>> Antoine Pitrou wrote:
>>> M.-A. Lemburg egenix.com> writes:
>>>> Please file a bug report for this. f.readlines() (or rather
>>>> the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
>>>>
Antoine Pitrou wrote:
> M.-A. Lemburg 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
Neil Hodgson wrote:
> M.-A. Lemburg:
>
>> ... and because of this, the feature is already available if
>> you use codecs.open() instead of the built-in open():
>
>So should I not add an issue for the basic open because codecs.open
> should be used for this ca
Antoine Pitrou wrote:
> M.-A. Lemburg egenix.com> writes:
>>
>> IMHO, it would be a lot better to add full Unicode support
>> for line breaks to the io layer. Given that the code for the
>> complicated handling of the CRLF combination is already there,
>> it&#x
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 ne
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 woul
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 Py
Zooko O'Whielacronx wrote:
> On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou 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 of
Python.
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.
>
>
Brett Cannon wrote:
> On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
>> On Wed, 23 Sep 2009 at 02:01, MRAB wrote:
>>>
>>> Dino Viehland wrote:
Is there a reason or a rule by which CPython reports different error
message for different failures to subscript?
For ex
David Lyon wrote:
> On Wed, 23 Sep 2009 09:49:16 +0200, "M.-A. Lemburg" wrote:
>
>> While it's a good idea to put up some form of meta-data
>> into an index, I wonder why you are using setup.cfg
>> for this.
>>
>> setup.cfg has traditionally
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 "bul
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 b
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 pro
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-arc
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 wo
Ronald Oussoren wrote:
>
> On 29 Sep, 2009, at 18:17, M.-A. Lemburg wrote:
>
>> Ronald Oussoren wrote:
>>>
>>>>> Use:
>>>>>
>>>>> ./configure --enable-framework --enable-universalsdk=/
>>>>>
>>>>
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 th
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 distuti
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
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,
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)
>>
>
> Greeting
Tarek Ziadé wrote:
> On Mon, Oct 5, 2009 at 4:27 PM, 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
Tarek Ziadé wrote:
> On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou 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 incompatibility is legi
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 too
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 havin
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
dict
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 informat
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
>
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
InnoSetup
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 m
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
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. Size
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 us
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 size
David Lyon wrote:
> On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers
> 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 people need) a
201 - 300 of 1090 matches
Mail list logo
