Paul Moore writes:
End users should not need packaging tools on their machines.
I think this desideratum is close to obsolete these days, with webapps
in the cloud downloading resources (including, but not limited to,
code) on an as-needed basis.
If you're *not* obtaining resources as-needed,
On Fri, Jun 22, 2012 at 3:20 PM, Donald Stufft donald.stu...@gmail.com wrote:
I don't want to argue over implementation details as I think that is
premature right now, so this
concept has a big +1 from me. RPM, deb, etc has a long history and a lot of
shared knowledge
so looking at them and
On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Paul Moore writes:
End users should not need packaging tools on their machines.
I think this desideratum is close to obsolete these days, with webapps
in the cloud downloading resources (including, but not
On 6/22/12 7:05 AM, Nick Coghlan wrote:
..
- I reject setup.cfg, as I believe ini-style configuration files are
not appropriate for a metadata format that needs to include file
listings and code fragments
I don't understand what's the problem is with ini-style files, as they are
suitable for
On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadé ta...@ziade.org wrote:
On 6/22/12 7:05 AM, Nick Coghlan wrote:
I don't understand what's the problem is with ini-style files, as they are
suitable for multi-line variables etc. (see zc.buildout)
yaml vs ini vs xxx seems to be an implementation
On 6/22/12 9:11 AM, Nick Coghlan wrote:
On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadéta...@ziade.org wrote:
On 6/22/12 7:05 AM, Nick Coghlan wrote:
I don't understand what's the problem is with ini-style files, as they are
suitable for multi-line variables etc. (see zc.buildout)
yaml vs ini vs
On Fri, Jun 22, 2012 at 5:24 PM, Tarek Ziadé ta...@ziade.org wrote:
On 6/22/12 9:11 AM, Nick Coghlan wrote:
On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadéta...@ziade.org wrote:
On 6/22/12 7:05 AM, Nick Coghlan wrote:
I don't understand what's the problem is with ini-style files, as they
are
Nick Coghlan ncoghlan at gmail.com writes:
On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadé tarek at ziade.org wrote:
On 6/22/12 7:05 AM, Nick Coghlan wrote:
I don't understand what's the problem is with ini-style files, as they are
suitable for multi-line variables etc. (see zc.buildout)
Nick Coghlan ncoghlan at gmail.com writes:
ini-style is often good enough, and failing that there's json. Or, you
just depend on PyYAML :)
Except when PyYAML is packaged and distributed using dist.yaml :-)
Regards,
Vinay Sajip
___
Python-Dev
I think json probably makes the most sense, it's already part of the stdlib for
2.6+
and while it has some issues with human editablity, there's no reason why this
json
file couldn't be auto generated from another data structure by the package
creation tool
that exists outside of the stdlib (or
On Fri, Jun 22, 2012 at 6:05 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft donald.stu...@gmail.com
wrote:
The idea i'm hoping for is to stop worrying about one implementation over
another and
hoping to create a common format that all the tools
On 22 June 2012 06:05, Nick Coghlan ncogh...@gmail.com wrote:
distutils really only plays at the SRPM level - there is no defined OS
neutral RPM equivalent. That's why I brought up the bdist_simple
discussion earlier in the thread - if we can agree on a standard
bdist_simple format, then we
Hello!
Playing with cpython source, I found some strange strings in
socketmodule.c:
---
if (flowinfo 0 || flowinfo 0xf) {
PyErr_SetString(
PyExc_OverflowError,
getsockaddrarg: flowinfo must be 0-1048575.);
return 0;
David Cournapeau cournape at gmail.com writes:
I agree having yet another format is a bit crazy, and am actually considering
changing bento.info to be a yaml. I initially did got toward a cabal-like syntax
instead for the following reasons:
- lack of conditional (a must IMO, it is even more
On 06/22/2012 10:40 AM, Paul Moore wrote:
On 22 June 2012 06:05, Nick Coghlanncogh...@gmail.com wrote:
distutils really only plays at the SRPM level - there is no defined OS
neutral RPM equivalent. That's why I brought up the bdist_simple
discussion earlier in the thread - if we can agree on a
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file (manifest) for the built-package. The latter is
normally generated by the build process (but follows a standard
nevertheless). Then
On 06/22/2012 11:38 AM, Donald Stufft wrote:
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file (manifest) for the built-package. The latter is
normally generated by the build process (but
Dmitriy Tochansky wrote:
Playing with cpython source, I found some strange strings in
socketmodule.c:
---
if (flowinfo 0 || flowinfo 0xf) {
PyErr_SetString(
PyExc_OverflowError,
getsockaddrarg: flowinfo must be 0-1048575.);
On Fri, 22 Jun 2012 15:05:08 +1000
Nick Coghlan ncogh...@gmail.com wrote:
So here's some sheer pie-in-the-sky speculation. If people like
elements of this idea enough to run with it, great. If not... oh well:
Could this kind of discussion perhaps go on python-ideas?
Thanks
Antoine.
Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no writes:
Well, but I think you need to care about the whole process here.
Focusing only on the end-user case and binary installers has the flip
side that smuggling in a back door is incredibly easy in compiled
binaries. You simply upload a
On Fri, Jun 22, 2012 at 10:38 AM, Donald Stufft donald.stu...@gmail.com wrote:
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file (manifest) for the built-package. The latter is
normally
On 06/22/2012 12:20 PM, David Cournapeau wrote:
On Fri, Jun 22, 2012 at 10:38 AM, Donald Stufftdonald.stu...@gmail.com wrote:
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file
On Friday, June 22, 2012 at 5:52 AM, Dag Sverre Seljebotn wrote:
The reason PyPI isn't one big security risk is that packages are built
from source, and so you can have some confidence that backdoors would be
noticed and highlighted by somebody.
Having a common standards for binary
On Friday, June 22, 2012 at 6:20 AM, David Cournapeau wrote:
If by manifest you mean the build manifest, then that's not desirable:
the manifest contains the explicit filenames, and those are
platform/environment specific. You don't want this to be user-facing.
It appears I misunderstood the
On 22 June 2012 11:28, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote:
And I'm saying that would encourage a culture that's very dangerous from a
security perspective. Even if many uses binaries, it is important to
encourage a culture where it is always trivial (well, as trivial as we
Paul Moore p.f.moore at gmail.com writes:
Signed binaries may be a solution. My experience with signed binaries
has not been exactly positive, but it's an option. Presumably PyPI
would be the trusted authority? Would PyPI and the downloaders need to
use SSL? Would developers need to have
On Jun 22, 2012, at 12:27 PM, Paul Moore wrote:
And what I am trying to say is that no matter how much effort gets put
into trying to make build from source easy, it'll pretty much always
not be even remotely trivial on Windows.
It seems to me that a Windows build service is something the Python
On 22/06/2012 13:14, Barry Warsaw wrote:
On Jun 22, 2012, at 12:27 PM, Paul Moore wrote:
And what I am trying to say is that no matter how much effort gets put
into trying to make build from source easy, it'll pretty much always
not be even remotely trivial on Windows.
It seems to me that
Nick Coghlan writes:
On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Paul Moore writes:
End users should not need packaging tools on their machines.
I think this desideratum is close to obsolete these days, with webapps
in the cloud
Hi,
On 6/22/12 1:05 AM, Nick Coghlan wrote:
On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft donald.stu...@gmail.com wrote:
The idea i'm hoping for is to stop worrying about one implementation over
another and
hoping to create a common format that all the tools can agree upon and
On 22 June 2012 13:39, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Paul Moore writes:
End users should not need packaging tools on their machines.
I think this
On Fri, Jun 22, 2012 at 2:24 PM, Paul Moore p.f.mo...@gmail.com wrote:
I suppose if you're saying that pip install lxml should download and
install for me Visual Studio, libxml2 sources and any dependencies,
and run all the builds, then you're right. But I assume you're not. So
why should I
On 22 June 2012 13:09, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
Signed binaries may be a solution. My experience with signed binaries
has not been exactly positive, but it's an option. Presumably PyPI
would be the trusted authority? Would PyPI and
On Fri, 22 Jun 2012 12:27:19 +0100
Paul Moore p.f.mo...@gmail.com wrote:
Signed binaries may be a solution. My experience with signed binaries
has not been exactly positive, but it's an option. Presumably PyPI
would be the trusted authority? Would PyPI and the downloaders need to
use SSL?
Zitat von Antoine Pitrou solip...@pitrou.net:
On Fri, 22 Jun 2012 12:27:19 +0100
Paul Moore p.f.mo...@gmail.com wrote:
Signed binaries may be a solution. My experience with signed binaries
has not been exactly positive, but it's an option. Presumably PyPI
would be the trusted authority?
Paul Moore p.f.moore at gmail.com writes:
As a user, I guess not that much. I may be misremembering bad
experiences with different things. We've had annoyances with
self-signed jars, and websites. It's generally more about annoying
can't confirm this should be trusted, please verify messages
martin at v.loewis.de writes:
See above. Also notice that such signing is already implemented, as part
of PEP 381.
BTW, I notice that the certificate for https://pypi.python.org/ expired a week
ago ...
Regards,
Vinay Sajip
___
Python-Dev
ACTIVITY SUMMARY (2012-06-15 - 2012-06-22)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3482 (+10)
closed 23435 (+51)
total 26917 (+61)
Open issues
More fuel; fire:
http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Ideally authors will be signing their packages (using gpg keys). Of course
how to distribute keys is an exercise left to the reader.
On Friday, June 22, 2012 at 11:48 AM, Vinay Sajip wrote:
martin at v.loewis.de (http://v.loewis.de) writes:
See above. Also notice that such signing is
On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
Key distribution is the real issue though. If there isn't a key
distribution infrastructure in place, we might as well not bother with
signatures. PyPI could issue x509 certs to packagers. You wouldn't be
able to verify that the
Not at the moment, but I could gather them up and make them public later today.
They
are very rough draft at the moment.
On Friday, June 22, 2012 at 1:09 PM, Alexandre Zani wrote:
On Fri, Jun 22, 2012 at 9:56 AM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
On 6/22/2012 6:57 AM, larry.hastings wrote:
http://hg.python.org/cpython/rev/ace45d23628a
changeset: 77567:ace45d23628a
user:Larry Hastings la...@hastings.org
date:Fri Jun 22 03:56:29 2012 -0700
summary:
Issue #14769: test_capi now has SkipitemTest, which cleverly checks
for
On 22/06/2012 17:39, Terry Reedy wrote:
On 6/22/2012 6:57 AM, larry.hastings wrote:
http://hg.python.org/cpython/rev/ace45d23628a
changeset: 77567:ace45d23628a
user:Larry Hastings la...@hastings.org
date:Fri Jun 22 03:56:29 2012 -0700
summary:
Issue #14769: test_capi now
Here's PEP 362:
http://www.python.org/dev/peps/pep-0362/
It adds easy introspection abilities to Python callables. After a
whirlwind of activity over the past several weeks we think it's ready.
All it needs now is an official pronouncement from some seasoned veteran
of the Python
I'll review it right now.
On Fri, Jun 22, 2012 at 11:31 AM, Larry Hastings la...@hastings.org wrote:
Here's PEP 362:
http://www.python.org/dev/peps/pep-0362/
It adds easy introspection abilities to Python callables. After a whirlwind
of activity over the past several weeks we think it's
This looks great, much better than the version I reviewed half a year
ago! Thanks you and others (especially Yuri) for all your efforts in
guiding the discussion and implementing as the discussion went along;
also thanks to Nick for participating to intensely.
Quick review notes:
(1) I don't
Does the feature freeze affect documentation enhancements? If it does,
can somebody review (and commit! :) issues:
http://bugs.python.org/issue14954
http://bugs.python.org/issue14617
Thanks! (And if not necessary before the feature freeze, sorry for the
noise.)
~Ethan~
Zitat von Ethan Furman et...@stoneleaf.us:
Does the feature freeze affect documentation enhancements?
No. Incorrect/missing documentation is always a bug (unless there
is a debate whether something is an implementation detail or a
language feature); bugs can be fixed at any time, and
Guido,
On 2012-06-22, at 2:52 PM, Guido van Rossum wrote:
This looks great, much better than the version I reviewed half a year
ago! Thanks you and others (especially Yuri) for all your efforts in
guiding the discussion and implementing as the discussion went along;
also thanks to Nick for
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
Guido,
On 2012-06-22, at 2:52 PM, Guido van Rossum wrote:
This looks great, much better than the version I reviewed half a year
ago! Thanks you and others (especially Yuri) for all your efforts in
guiding the
Am 22.06.2012 20:52, schrieb Guido van Rossum:
(5) Too bad there's no proposal for adding signatures to builtin
functions/methods, but understood.
Larry et al. did an experiment with a mutable __signature__ attribute to
PyCFunction. He immediately backed out and removed the attribute as I
Am 22.06.2012 21:10, schrieb Yury Selivanov:
I think that if a function lacks an annotation, that should be reflected
in the same way for its signature.
Currently:
if hasattr(signature, 'return_annotation'):
If we use Signature.empty:
if signature.return_annotation is not
Hi,
As mentioned in the commit message for 96513d71e650, creating a type
using PyType_FromSpec seems to leak references when the type is
instantiated. This happens with SSLError:
e = ssl.SSLError()
sys.getrefcount(ssl.SSLError)
35
e = ssl.SSLError()
sys.getrefcount(ssl.SSLError)
36
e =
On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
Guido,
On 2012-06-22, at 2:52 PM, Guido van Rossum wrote:
...
'empty' will
On 06/22/2012 12:21 PM, Christian Heimes wrote:
The PEP is already complex enough and went to several incarnations. It
was a wise decision to focus on the features that could be implemented
before the first beta is released. Kudos for pulling it off, Larry!
Guys, guys! I have done
On 06/22/2012 11:21 AM, MRAB wrote:
On 22/06/2012 17:39, Terry Reedy wrote:
You sensibly only test printable ascii chars, which are in the
contiguous range 32 to 127 inclusive. So it makes no sense to claim
otherwise and then deny the wrong claim, or to enlarge the range and
then shrink it
Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
Yes, I meant optional. Would 'name(arg1, *, [arg2])' be
Am 22.06.2012 21:32, schrieb Larry Hastings:
On 06/22/2012 12:21 PM, Christian Heimes wrote:
The PEP is already complex enough and went to several incarnations. It
was a wise decision to focus on the features that could be implemented
before the first beta is released. Kudos for pulling it
On 2012-06-22, at 3:47 PM, Ethan Furman wrote:
Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
Yes, I
On Fri, 22 Jun 2012 21:23:10 +0200
Antoine Pitrou solip...@pitrou.net wrote:
Hi,
As mentioned in the commit message for 96513d71e650, creating a type
using PyType_FromSpec seems to leak references when the type is
instantiated. This happens with SSLError:
The patch in
On 6/22/2012 3:00 PM, Ethan Furman wrote:
can somebody review (and commit! :) issues:
http://bugs.python.org/issue14954
About weakref, no response yet.
Beyond my knowledge.
http://bugs.python.org/issue14617
About __hash__, a short response from Éric Araujo
I might look at this.
--
Terry
90% of the way through recloning cpython on Win7, I got
Putty Error: Network error: software called connection abort
Tortoise hg said
abort: stream ended unexpectedly (got 53602 bytes, expected 55236)
Two retries give same Putty error almost immdiately, with hg message
no suitable response from
On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 06/22/2012 10:40 AM, Paul Moore wrote:
On 22 June 2012 06:05, Nick Coghlanncogh...@gmail.com wrote:
distutils really only plays at the SRPM level - there is no defined OS
neutral RPM equivalent.
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
Guido,
On 2012-06-22, at 2:52 PM, Guido van Rossum wrote:
Of these, only (1) is a blocker for PEP acceptance -- I'd either like
to see this defended
On 6/22/2012 3:24 PM, Yury Selivanov wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
Hardly, because that's not valid syntax. I'd write name(arg1, *,
arg2=default).
Like
replace(*, name=default, kind=default, default=default,
On 6/22/2012 2:21 PM, MRAB wrote:
On 22/06/2012 17:39, Terry Reedy wrote:
On 6/22/2012 6:57 AM, larry.hastings wrote:
http://hg.python.org/cpython/rev/ace45d23628a
changeset: 77567:ace45d23628a
user:Larry Hastings la...@hastings.org
date:Fri Jun 22 03:56:29 2012 -0700
On Fri, Jun 22, 2012 at 9:11 PM, PJ Eby p...@telecommunity.com wrote:
On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 06/22/2012 10:40 AM, Paul Moore wrote:
On 22 June 2012 06:05, Nick Coghlanncogh...@gmail.com wrote:
distutils really only plays
On Tue, 19 Jun 2012 17:46:30 -0400
Éric Araujo mer...@netwok.org wrote:
With beta coming, a way to deal with that unfortunate situation needs
to be found. We could (a) grant an exception to packaging to allow
changes after beta1; (b) keep packaging as it is now under a provisional
On 2012-06-22, at 4:20 PM, Terry Reedy wrote:
On 6/22/2012 3:24 PM, Yury Selivanov wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
Hardly, because that's not valid syntax. I'd write name(arg1, *,
arg2=default).
Like
replace(*, name=default, kind=default,
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 space is also not usable and perhaps not
worth testing.
Au contraire! I grant you, it's hard to imagine how using it would be a
good idea. But strictly speaking it is *usable*. (And what is this
thread about if not
On 2012-06-22, at 3:25 PM, Christian Heimes wrote:
Am 22.06.2012 21:10, schrieb Yury Selivanov:
I think that if a function lacks an annotation, that should be reflected
in the same way for its signature.
Currently:
if hasattr(signature, 'return_annotation'):
If we use
On 6/22/2012 6:09 AM, Vinay Sajip wrote:
Easy enough on Posix platforms, perhaps, but what about Windows?
Every time windows users download and install a binary, they are taking
a chance. I try to use a bit more sense than some people, but I know it
is not risk free. There *is* a third
Yury Selivanov wrote:
On 2012-06-22, at 3:47 PM, Ethan Furman wrote:
Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
On 2012-06-22, at 4:58 PM, Ethan Furman wrote:
That looks strange to me -- I suggest putting brackets around each one, like:
replace(*, [name=optional,] [kind=optional,] [default=optional,]
[annotation=optional]) - Parameter
Isn't it too much? The PEP clearly indicates '=optional' is
On Friday, June 22, 2012 at 4:55 PM, Terry Reedy wrote:
Every time windows users download and install a binary, they are taking
a chance. I try to use a bit more sense than some people, but I know it
is not risk free. There *is* a third party site that builds installers,
but should I
I am accepting the PEP. Congrats Yuri! (And others who feel they deserve it. :-)
On Fri, Jun 22, 2012 at 2:04 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-22, at 4:58 PM, Ethan Furman wrote:
That looks strange to me -- I suggest putting brackets around each one, like:
On 2012-06-22, at 5:26 PM, Guido van Rossum wrote:
I am accepting the PEP. Congrats Yuri! (And others who feel they deserve it.
:-)
Great! Larry will merge the implementation then.
Larry, Brett and I worked on the PEP together (~200 emails in private
discussions),
so everybody deserves ;)
On 22/06/2012 21:45, Larry Hastings wrote:
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 space is also not usable and perhaps not
worth testing.
Au contraire! I grant you, it's hard to imagine how using it would be a
good idea. But strictly speaking it is *usable*.
On 06/22/2012 03:48 PM, MRAB wrote:
On 22/06/2012 21:45, Larry Hastings wrote:
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 space is also not usable and perhaps not
worth testing.
Au contraire! I grant you, it's hard to imagine how using it would be a
good idea.
Since worked ok.
--
Terry Jan Reedy
___
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
81 matches
Mail list logo
