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
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 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 str
On 22/06/2012 21:45, Larry Hastings wrote:
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 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
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 ;)
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 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:
>>
>> replace(*, [name=,] [ki
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
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=,] [kind=,] [default=,]
> [annotation=]) -> Parameter
Isn't it too much? The PEP clearly indicates '=' is just
a notation for an optional paramet
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
wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
wrote:
Yes, I meant optional. Would 'n
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 party
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 u
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 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 wanton pe
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=).
>>
>> Like
>>
>> replace(*, name=, kind=, default=,
>>
On Tue, 19 Jun 2012 17:46:30 -0400
Éric Araujo 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
> status, with due
On Fri, Jun 22, 2012 at 9:11 PM, PJ Eby wrote:
> On Fri, Jun 22, 2012 at 5:22 AM, Dag Sverre Seljebotn
> wrote:
>>
>> On 06/22/2012 10:40 AM, Paul Moore wrote:
>>>
>>> On 22 June 2012 06:05, Nick Coghlan wrote:
distutils really only plays at the SRPM level - there is no defined OS
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
date:Fri Jun 22 03:56:29 2012 -0700
summary:
Issue #14769:
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=).
Like
replace(*, name=, kind=, default=,
annotation=) -> Parameter
or
replace
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
> On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
> 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 vigorously (maybe i
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 Coghlan wrote:
>>
>>> distutils really only plays at the SRPM level - there is no defined OS
>>> neutral RPM equivalent. That's w
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 r
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
On Fri, 22 Jun 2012 21:23:10 +0200
Antoine Pitrou 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 http://bugs.python.org/issue15142
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
>> wrote:
>>> On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
>>>
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
wrote:
> Yes, I meant optional. Would
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 pulli
Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov
wrote:
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
wrote:
Yes, I meant optional. Would 'name(arg1, *, [arg2])' be better?
Hardly, because that's not valid synta
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 again
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 next-to-not
On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov
wrote:
> On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
>
>> On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
>> wrote:
>>> Guido,
>>>
>>> On 2012-06-22, at 2:52 PM, Guido van Rossum wrote:
> ...
>>> 'empty' will also work. When python-dev col
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
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 i
On Fri, Jun 22, 2012 at 12:21 PM, Christian Heimes wrote:
> 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
> PyCFun
On 2012-06-22, at 3:18 PM, Guido van Rossum wrote:
> On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
> wrote:
>> Guido,
>>
>> On 2012-06-22, at 2:52 PM, Guido van Rossum wrote:
...
>> 'empty' will also work. When python-dev collectively decided to
>> go with missing attributes, 'empty' didn't
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
expl
On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov
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 discussion and i
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 fo
Zitat von Ethan Furman :
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 documentation
bugs in part
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~
___
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 like
I'll review it right now.
On Fri, Jun 22, 2012 at 11:31 AM, Larry Hastings 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 ready.
>
>
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 commu
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
date:Fri Jun 22 03:56:29 2012 -0700
summary:
Issue #14769: test_capi now has SkipitemTest, whi
On 6/22/2012 6:57 AM, larry.hastings wrote:
http://hg.python.org/cpython/rev/ace45d23628a
changeset: 77567:ace45d23628a
user:Larry Hastings
date:Fri Jun 22 03:56:29 2012 -0700
summary:
Issue #14769: test_capi now has SkipitemTest, which cleverly checks
for "parity" between P
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 (mailto:donald.stu...@gmail.com)> wrote:
> > On Friday, June 22,
On Fri, Jun 22, 2012 at 9:56 AM, Donald Stufft wrote:
> 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 cer
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
On Fri, Jun 22, 2012 at 9:35 AM, Donald Stufft wrote:
> Ideally authors will be signing their packages (using gpg keys). Of course
> how to distribute keys is an exercise left to the reader.
Key distribution is the real issue though. If there isn't a key
distribution infrastructure in place, we m
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:
> v.loewis.de (http://v.loewis.de)> writes:
>
> >
> > See above. Also notice that such signing is alre
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:
http://mail.python.org/mailman/options/python-dev/archive%
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 wit
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 mailing
Paul Moore 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 which
Zitat von Antoine Pitrou :
On Fri, 22 Jun 2012 12:27:19 +0100
Paul Moore 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
On Fri, 22 Jun 2012 12:27:19 +0100
Paul Moore 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? Would developers
On 22 June 2012 13:09, Vinay Sajip wrote:
> Paul Moore 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
>> u
On Fri, Jun 22, 2012 at 2:24 PM, Paul Moore 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 need to insta
On 22 June 2012 13:39, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
> > On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull
> wrote:
> > > Paul Moore writes:
> > >
> > > > End users should not need packaging tools on their machines.
> > >
> > > I think this desideratum is close to o
Hi,
On 6/22/12 1:05 AM, Nick Coghlan wrote:
On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft 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
create/install.
Right, and this is w
Nick Coghlan writes:
> On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull
> 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
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 t
On Jun 22, 2012, at 07:49 AM, Vinay Sajip wrote:
>The format-neutral alternative I used for logging configuration was a
>dictionary schema - JSON, YAML and Python code can all be mapped to
>that. Perhaps the relevant APIs can work at the dict layer.
I don't much care whether it's ini, json, or ya
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 Py
Paul Moore 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 signing keys
On 22 June 2012 11:28, Dag Sverre Seljebotn 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 can
> possibly make it, in
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 t
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 bina
On 06/22/2012 12:20 PM, David Cournapeau wrote:
On Fri, Jun 22, 2012 at 10: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.
On Fri, Jun 22, 2012 at 10: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
Dag Sverre Seljebotn 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 binary t
On Fri, 22 Jun 2012 15:05:08 +1000
Nick Coghlan 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.
__
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-104
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
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 10:40 AM, Paul Moore wrote:
On 22 June 2012 06:05, Nick Coghlan 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_sim
David Cournapeau 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 useful for
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;
On 22 June 2012 06:05, Nick Coghlan 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 can more cleanly
On Fri, Jun 22, 2012 at 6:05 AM, Nick Coghlan wrote:
> On Fri, Jun 22, 2012 at 10:01 AM, Donald Stufft
> 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
> > create/inst
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 (o
Nick Coghlan 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 mailing list
P
Nick Coghlan gmail.com> writes:
>
> On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadé 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
On Fri, Jun 22, 2012 at 5:24 PM, Tarek Ziadé wrote:
> On 6/22/12 9:11 AM, Nick Coghlan wrote:
>>
>> On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadé 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 f
On 6/22/12 9:11 AM, Nick Coghlan wrote:
On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadé 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
On Fri, Jun 22, 2012 at 4:42 PM, Tarek Ziadé 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 detail, and my
82 matches
Mail list logo
