ery sure you'd agree on that. But it
is an ongoing struggle for whatever reason that I've been having.
I'm sure your guidance can resolve the issues easily..
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
on
> mailing lists you can claim you came up with the initial idea, but I
> am sure a ton of people provided feedback which makes ownership of any
> idea practically moot.
Claiming ownership? No No. Lets not go there.
A worklist and checkin rights would completely suffice.
David
pts could more easily
access/update the version number as required.
Of course, setup.cfg wouldn't get uploaded. Nobody would
want to do that.
But distutils would create the .PKG_INFO file and metadata
from configuration, and not from hardcoded string values
within setup.py as it does now.
Da
hosts themselves no longer need to be the
> gating factor for most issues.
Depends on where the machines are. There are good tools do check all
automatically. Nagios is one.
Anyway, this would suite my work schedule for the next 12 months.
Do we already have the machines? or do they need to be a
ut the
master showed it as down. Stopping and restarting the buildbot,
forcing it to reconnect, cleaned things up, but I have to monitor the
web status page which is a manual process.
And since it's the master's perspective that really matters when it
comes to a buildbot
Dave M.
On 27 Sep 2009, at 07:56, "Martin v. Löwis" wrote:
As a side note, I would be in favor of dropping the concept of a
mask
from the library, and only support a prefix length.
-1
IPv6 doesn't support masks at all, and even for IPv4, I think there
are conventions (if not RFCs) agai
On Sun, Sep 27, 2009 at 9:26 PM, Greg Ewing wrote:
> Would you be kind enough to explain exactly what use
> case you have for retaining this information?
>
> Apologies if you've done so before -- I've been
> trying to follow this discussion, but that point
> doesn't seem to have come through clear
ays have to look at
distutils sources since the docs are vastly insufficient, and even
then, the code is so bad that quite often the only way to interact
with distutils is to "reverse engineer" its behavior by trial and
error.
cheers,
David
___
ng around for years.
And your post is now asking "why no windows users?"
Go figure.. nobody answers them or takes issues seriously.
Distutils for windows is very, very dead.. grave-ware in-fact.
It should be quite obvious that windows users are forked off..
Why would windows p
d reasonable
proposal.
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 download url
gle one working
and not bringing more problems that it solved. One core problem being
the exponential number of combination (package A depends on B and C, B
depends on one version of D, C on another version of D). Being able to
install *some* libraries in multiple versions is
upport softlink. The only inconvenience of stow compared to
virtual env is namespace packages, but that's because of a design flaw
in namespace package (as implemented in setuptools, and hopefully
fixed in the upcoming namespace package PEP).
Virtualenv provid
Distribute. My user experience with setuptools was that it
wasted a lot of my time unnecessarily.
I'm planning to put Distribute support in the Python Package
Manager project (pythonpkgmgr) for it's next release.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> of the package file itself.
>
> Basically, most of the mechnisms are already there, they just need
> some extra care.
Maybe you're right. I'll look into it.
> BTW: Who would I need to contact for the PyPI side to work out
> an upload_url distutils command ?
pypi i
e to just mount a package manager application
in the "Programs" + "Python X.Y" menu. Users would surely find it there.
Regards
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
s roadmap for windows is to apply more freeze spray.. it's a
cryogenic source code freezing iceberg...
It's just there for windows users to crash their boats into..
Try and see for yourself..
David
___
Python-Dev mailing list
Python-Dev@python
t should
be possible to disable it).
The main problem with bdist_wininst installers is that they don't work
with setuptools dependency stuff (at least, that's the reason given by
windows users for a numpy egg on windows, whereas we used to on
ssues, and try to come
to a consensus.
Even if that tool would simply allow them to choose:
- PIP
- Distribute
- Easy Install
- Python Package Manager
>From there, users could explore each offer on it's
own merits.
I'm interes
it's 'python' and 'development' and it's
not in distutils then some discussion of it should be allowed here.
What I am really talking about is the menu shortcuts in the cpython
distribution for windows. And how they can be improved to help
windows users.
interest in having a package
> manager tool included with Python" rather than ask us out of the blue
what
> GUI you should use.
ok - but I think I know the answer to that.. you answer it next.
> David, you are making a huge leap here thinking that we even want a
package
> manage
f, but I'm not sure whether that mechanism
> might have been removed. For the system messages, there is a way to
> turn them off in the parent process. David Bolen (IIRC) had developed
> a patch, but I think this patch only runs on his system(s).
Yes, process-stopping dialogs have pro
st
that feature to the buildbot developers.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ig
impact in terms of availability) makes it hard to dedicate time to
that compared to my "real world" work :-)
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
at is shell support
in the python windows distribution so that you can right click an
.egg and install it.
I don't see how that can be achieved by following the workprocess
that you describe above.
David
___
Python-Dev mailing list
Python-Dev
not have the resources at the moment.
- how to maintain a compatible C API across 2.x and 3.x
- is it practically possible to support and maintain numpy from 2.4
to 3.x ? For example, I don't think the python 2.6 py3k warnings are
very useful when you need to mai
ation with other packages. We can port to PEP 3118 without
porting to 3.x, and we can port to 3.x without taking care of PEP
3118.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
entation is sparse :) The only helpful reference I have found so
far is an email by MvL concerning psycopg2 port.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
for 2.4, the latter is by far my preferred
choice today (RHEL still require 2.4, for example).
cheers,
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
to3 the wrong way. On my machine, with
2to3 from 3.1.1, it takes ~ 1s to convert one single file of 200
lines, and converting a tiny subset of numpy takes > one minute.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
for it to be some proprietory out
out of python object.
Call it the new Tarek egg...
Then refactor distutils build to focus on good egg creation..
Many people will help you.. including myself..
David
___
Python-Dev mailing list
Python-Dev@
lots of python
platforms, distutils can easily pop them out, they are well
documented and relatively trouble free.
Most importantly, credit for the original idea goes back
to PJE and everything gets refactored to make it 'nice'.
I don't think it's a massive refactoring operati
le
work item..
And to me, it doesn't seem any harder than just selecting 'djlyon'
on the python tracker for some work items...
Surely those PEPs all amount to 300+ lines of code. With two people
working on it, that's only surely 150+ lines of code each... That
shouldn't
andl
o [Distutils] Alternate static metadata PEP submission... David
Lyon
o [Distutils] Alternate static metadata PEP submission...
Floris Bruynooghe
+ [Distutils] Alternate static metadata PEP submission...
Georg Brandl
+ [Distutils] Al
rnate-metadata installation proposal
and I accept your feedback. What I can do is clarify that my
proposal is not for a build system but for a metadata installation
scheme based on a static setup.py, existing metadata and use of
"python -m setup install" for invoca
27;ve done manual builds on both, as well as reissuing a few
builds through the master, but if anyone notices anything strange
please feel free to drop me a note.
-- David
PS: I did discover one interesting bug by starting fresh on
Windows. It turns out that one of the distutils tests assumes Notep
On Tue, Nov 10, 2009 at 10:07 PM, Greg Ewing
wrote:
> Seems to me the only kind of IDE that it makes sense to
> ship with Python is one that is written in Python and
> maintained by the core developers. Anything else is best
> left as a third party package for download by those
> who want to use i
On Wed, Nov 11, 2009 at 1:50 PM, Fred Drake wrote:
> On Wed, Nov 11, 2009 at 12:59 PM, Echo wrote:
>> We just need a PyEmacs. Written in python, extensible in elist and
>> python. Nice and simple ;-D
> I'd even give up the elisp support if I could have Python in my Emacs.
Have you tried Pymacs?
_
he time to contribute to make it better or B> It
> changes.
>
Where is the code for PyPi? I took a quick look and didn't turn up anything.
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
Python-Dev mailing li
On Thu, Nov 12, 2009 at 12:06 PM, Jacob Kaplan-Moss wrote:
> On Thu, Nov 12, 2009 at 11:02 AM, David Stanek
> wrote:
> > Where is the code for PyPi? I took a quick look and didn't turn up
> anything.
>
> https://svn.python.org/packages/trunk/pypi/
>
> I'
On Fri, 13 Nov 2009 00:44:30 +0100, Xavier Morel
wrote:
> If pypi one day has a CPAN-style buildbot farm allowing it to test the
> package on any platform under the sun, that can be included, the tests
can
> be included as well but given the number of testing solutions (and
coverage
> discovery as
Hi All,
What do people think about this idea? I've actually started writing
something to try to to do this and create sn automated scoring system
for the packages on pypi.
It was started last week based on Guido's comments on the distutils
mailing list.
> Why not rate ( or auto-rate) packages on
On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. Löwis"
wrote:
> http://pycheesecake.org/
Ok, so what is the current status on it?
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
.
Processing so many packages for so many platforms is a monstrous
task. Nobody should get the idea it can be done by the weekend.
It will take a few months... well at the rate I am going
anyway..
David
___
Python-Dev mailing list
Python-Dev@python.o
ever run recently on
the Windows build slaves?
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
David Bolen writes:
> (...)
> I would have sworn they used to get run, but now I'm not so sure.
> Perhaps I'm remembering older Python releases with VS.NET 2003, since
> the MSVC9 versions of the CRT and the SXS stuff was new with VS 2008 I
> think.
>
> Does anyon
"R. David Murray" writes:
> The buildbot pages appear to be pretty messed up now. I get many 404s
> (ex: the above url, the all stable builders page), although some seem to
> work (ex: the all builders page), and if I stick an 'all' into the URL
> for my build
stributions package things.
Especially if the data can be obtained for every build (autoconf and
VS-based), this would help packages which use something else than
distutils for their build.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Has anyone else looked at using Coccinelle/spatch[1] on CPython source
code?
It's a GPL-licensed tool for matching semantic patterns in C source
code. It's been used on the Linux kernel for detecting and fixing
problems, and for autogenerating patches when refactoring
(http://coccinelle.lip6.fr/im
On Sun, 2009-11-15 at 12:42 +, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
> >
> > This cannot work on all platforms, when our Makefile is not shipped
> > with python but python-devel. (like Fedora)
>
> This practice is stupid anyway, because it means you have to install
> python-
On Tue, 2009-11-17 at 13:03 -0800, Brett Cannon wrote:
> On Mon, Nov 16, 2009 at 12:27, David Malcolm wrote:
> > Has anyone else looked at using Coccinelle/spatch[1] on CPython source
> > code?
[snip]
> Running the tool over the code base and reporting the found bugs woul
On Tue, 2009-11-17 at 19:45 -0500, Terry Reedy wrote:
> A.M. Kuchling wrote:
> > On Mon, Nov 16, 2009 at 03:27:53PM -0500, David Malcolm wrote:
> >> Has anyone else looked at using Coccinelle/spatch[1] on CPython source
> >> code?
> >
> > For an excellent e
he current
poll-with-timed-sleep approach.
The overhead (CPU, but most notably latency) of that approach (which
also directly impacts Queues) has historically been my top reason in
various applications on Windows to have to implement my own Queue or
Condition structures using
at someone tried to manually
trigger a build but put the wrong branch information (or left it
blank) on the submission form.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
I don't think there's anywhere separate, and generally (recent history
being a bit different) buildbot related stuff has been very low
volume. So this list is probably appropriate (given what the
buildbots are being used for). I expect if it gets too noisy we'll
hear about it :-)
worth the effort to track down
at the time, given that nobody had seemed to notice the lack of
builds.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
and the fact that the
account running the build slave is in the wheel(0) group, so
directories/files created beneath /tmp get a group of 0 rather than
the user's gid. That affects the temporary files in the distutils
test, which is expecting a default
oper might not understand all those
details and might not be interested to learn.
I accept that the terminology is good on linux.. but it's near
meaningless on windows - for me - anyway.
David
On Sat, 12 Dec 2009 21:02:13 +0100, Tarek Ziadé
wrote:
> Hello,
>
> A while ago I
Data". Why can not
python respect the operating system directions for well behaved
apps?
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
top.
Not the other way round, sitting beneath the language interpreter.
This is pretty much the way it has been for windows for close on
15 years now.
Regards
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
nable Windows specific ways
> to get them), but sysconfig isn't trying to solve that for you and I
> agree it should not attempt to.
So under windows, then, what is it trying to solve? Thats what I am
asking.
David
___
Python-Dev m
appdata directory.
Sure. There's growing support within the python interpretor for things
like that. But Mercurial uses an external installer. Like NSIS, to
overcome the deficiencies that I am pointing out.
> .. it isn't targetted at application developers on any operating system.
I se
perphaps sysconfig could help me get my
helloworld.py application into a \Program Files\hello world
directory and everything would be rosy.
But not yet. So I will wait.
> Distutils isn't perfect but solves the need of installing public
> modules and packages q
s to attract
the attention of our commercial sponsors attention. Because
they're always interested in getting new toys and utilising
their resources in the most efficient way.
If we do the above, incorporate tested packages from pypi, it's
possible that the glow of CPAN might be tarnished somewha
over time.
If it's only +1 from one person to make python more
network centric with sysconfig in 2010, then so be it.
Have a nice day.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
ct. It was started in 2005 and
that
seems like a long time to hold things up. There's always time for a 1.3
version in two years time if there is an unstoppable problem here - but
I can't see any.
As an application developer, I have to side with Tarek. Lets get this
finalised.
Thank yo
xercise than one PEP every
year or two years.
Whilst I agree that the core language is really great and the
rate of progress can happily slow. It would be nice to see
the rate of progress of other areas, such as the metadata side,
increase a little.
That wouldn't break policy
David
_
ans 'roughly', but it requires too much thought and is ambiguous. 2.5
is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant
to typical packaging scenarios.
I
ich is a requirement
> that no single version can meet.
No, it means a library requires either python 2.5 *OR* python 2.6 to be
installed properly.
If not, the implication is that the user will be prompted to install anyway.
David
___
Python-Dev
ns.
A user can still try to install on other versions. But
they would get a warning and would do so at their own
risk.
There's no need for extra operator characters as far
as I can see. The comma method proposed originally
seemed to do everything.
David
__
k a python version) and they
know it works pretty well.
It's then up to the user if they want to use it on any other
version.
That's why I don't think we need the '=' '>=' operator
characters to represent typical use cases.
If there's any use-case, tha
> david.l...@preisshare.net writes:
>
> > With respect, it's not a very common use case for a developer to
> > say that package needs a python interpretor 'older' than 2.5.
>
> Of course it is. I don't claim it is the majority of cases out there,
> but stable versions of many of the packages I u
verything between 2.5 and 2.7 and then
everything in the 3 series.
This would make it very simple.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
the ..
will translate to 'to'.
So taking your example more closely might be:
Requires-Python: [2.5]..[2.7]; [3.1]..
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
than a 'less-than' operator. There just
comes a point where people don't bother with old
interpreter versions)
That wraps it up for the vocal faction...
Happy new year
David
___
Python-Dev mailing list
Python-Dev@python.org
http://m
ke this:
> Requires-Python: 2.5:2.6
That will catch all 2.6 unreleased versions (security fixes et la)
and not 2.7
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
quires-Python: 2, 3
To me that would cover all 8 versions.
As for the testing thing, well that's the cpan debate.. another thread.
> (and if you don't test exhaustively, just use the "2.5+" notation)
Exactly.
David
___
Pyth
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray"
wrote:
> What about specifying that the package works only with, say, 2.6.2 or
> earlier (because of some problem introduced by 2.6.3)? That could get
> pretty darn verbose. (Also remember we aren't just talking about
s effort is targeted.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ambiguity we had.
Ok.
> Environment markers
>..
>Here are some example of fields using such markers:
>
>Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+
That's simpler, shorter, and less a
a system.
I feel that this would really simplify the packaging
landscape, making it much easier for the scientific
community and others to do python software installs.
This would allow us to perphaps have something even
*more modern* than CPAN.
So yes, getting PEP-345 right is important to me.
H
rs on python 3 (so they don't have to run it themselves),
then it would be like an even bigger tv screen in a bigger lounge
room and it would assist in drawing them over.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
ys. And
there are tools in the outside world (bzr,svn,mercurial) that allow us to
do it very easily.
Let's have that support in python; it will make life easier.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
ep my comments unheated and unwitty.
Having said that, PEP-345 is *super-important*. A week or two or three
more discussion and the issues can be resolved.
We all just want to focus on being productive. It would be a great
accomplishment for you to get PEP-345 approved and likewise f
chnical term "perception of quality".
If the PEP process is as unblocked as the
documentation implies, implying that anybody
can contribute to Python 3. Then there shouldn't
be any issue.
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
nversion/reporting logic is a huge improvement. And
> that's
> only a small part of the picture.
In no way could I disagree with you.
Ascii works fine for us here - but I guess we're lucky.
Just keep pushing python 3 and have a nice day..
David
kaging needs six
months of that to repair the years and years of neglect
and stagnation. Even if it is only beer and bus fare
money. It just needs a temporary shot of adrenalin in
the arm.. so to speak..
Regards
David
___
Python-Dev maili
and expectations.
If you ask us all to put in a big year and
buy you a beer at the end.. I'm certain we
all will.
Every little bit of inspiration and direction
counts for a lot...
Best Regards
David
___
Python-Dev mailing list
Python-Dev@
Hi Barry,
That looks very interesting...
So does that mean we could update the stdlib for a given
python version using this ?
David
> I've just updated the Launchpad mirrors for the 4 active Python branches,
> trunk, py3k, 2.6, and 3.1. These used to mirror the defunct Bazaar
>
at it once was (not saying it isn't now).
Were you offering me an experimental branch somewhere
for python 3 SCM integration ?
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
eek. Did you just say ?:
"Barry made a bizarre mirror of the python suvern tree. Not a
python with a buzzer included."
Anyway.. Maybe I do get what your talking about. Even if you do
talk with a strange accent. :-)
David
___
Python-
great in
a production environment. No packaging solution
can come close.
So why not have python SCMs included as batteries in python..
All these arguments I can take off to the stdlib list when I get
the chance..
David
___
Python-Dev
> "David Lyon" writes:
>
>> Being honest, if wonderful libraries like Sphinx and Mercurial and Git
>> and BZR can't make it into the stdlib, then there is no hope for even
>> newer code to get in there.
>
> Those are applications, not libraries. Applic
will be proved wrong.
At the end of the day, we are making a decision about whether
the language is 'set-in-stone' or whether it is still
evolving.
To me, Python 1.x had it's own distinct "era", as has
Python 2.x
Hoping that the Python 3 era can be a little more fl
I'm thinking of making this downstream change to Fedora's site.py (and
possibly in future RHEL releases) so that the default encoding
automatically picks up the encoding from the locale:
def setencoding():
"""Set the string encoding used by the Unicode implementation. The
default is 'a
On Wed, 2010-01-20 at 22:37 +0100, M.-A. Lemburg wrote:
> David Malcolm wrote:
> > I'm thinking of making this downstream change to Fedora's site.py (and
> > possibly in future RHEL releases) so that the default encoding
> > automatically picks up the encoding
On Thu, 2010-01-21 at 00:06 +0100, "Martin v. Löwis" wrote:
> > Why only set an encoding on these streams when they're directly
> > connected to a tty?
>
> If you are sending data to the terminal, you can be fairly certain
> that the locale's encoding should be used. It's a convenience feature
> f
On Wed, 2010-01-20 at 14:27 -0800, Collin Winter wrote:
[snip]
> At a high level, the Unladen Swallow JIT compiler works by translating a
> function's CPython bytecode to platform-specific machine code, using data
> collected at runtime, as well as classical compiler optimizations, to improve
> t
On Thu, 2010-01-21 at 23:42 +0100, "Martin v. Löwis" wrote:
> > With my "downstream distributor of Python" hat on, I'm wondering if it
> > would be feasible to replace the current precompiled .pyc/.pyo files in
> > marshal format with .so/.dll files in platform-specific shared-library
> > format, s
On Thu, 2010-01-21 at 22:21 +0100, "Martin v. Löwis" wrote:
> > Where the default *file system encoding* is used (i.e. text files are
> > written or read without specifying an encoding)
>
> I think you misunderstand the notion of the *file system encoding*.
> It is *not* a "file encoding", but the
d up. There's little chance that any of Guido's issues
can be addressed. That's just my take on it anyway.
Yes.. and finishing with your suggestions... we can
experiment.. play with all the undocumented and unobvious
features. And really, in a sense you are right. That is
all we can d
401 - 500 of 1906 matches
Mail list logo
