Daniel Diniz wrote:
Apocalypse Python !!, you say? Maybe something that conveys a security
message or anything that doesn't relate to the end of the world could
work better.
I guess the idea is meant to be that it's safe enough to
use for something that would result in the end of the
world if
Maciej Fijalkowski gmail.com> writes:
>
> Is py3k branch even passing all tests on all buildbots all the time?
As much as other branches do (that is, not much, due to the flakiness of some of
the tests and the lack of buildbot maintenance).
> I don't think
> svn head is the right thing to look
On Sun, Jun 21, 2009 at 5:05 PM, Daniel Diniz wrote:
> Hi David,
>
> wrote:
>>
>> It appears that one possibility of investigation into the development of a
>> safety-critical variant of the python language
>
> There is some interesting work related to a safety-critical variant of Python.
>
>> wou
Hi David,
wrote:
>
> It appears that one possibility of investigation into the development of a
> safety-critical variant of the python language
There is some interesting work related to a safety-critical variant of Python.
> would be to conduct run time
> error analysis of the source code that
Fredrik Lundh wrote:
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
Fredrik Lundh wrote:
I think you really need to get Fredrik Lundh to comment on it. If he
can't predict when he'll be able to review the changes, maybe he can
accept releasing control of xmlrpclib.
Pointer to the pa
omega_force2...@yahoo.com wrote:
It appears that one possibility of investigation into the development of
a safety-critical variant of the python language would be to conduct run
time error analysis of the source code that is responsible for producing
the python language. Therefore, I will no
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
> While I have your attention, please also review
>
> http://bugs.python.org/issue6233
I'm pretty sure that fix is the wrong fix - afaik, _encode is used to
encode tag/attribute names, and charrefs don't work in that context.
___
I'm against syntax for this, for all the reasons stated by others.
Jerry Chen wrote:
Just one last note: I think my end goal here was to preserve the
visual clarity and separation between format string and format
parameters, as I much prefer:
"%s %s %s" % (1, 2, 3)
over
"{0} {1} {2}".format(1
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
> Fredrik Lundh wrote:
>>> I think you really need to get Fredrik Lundh to comment on it. If he
>>> can't predict when he'll be able to review the changes, maybe he can
>>> accept releasing control of xmlrpclib.
>>
>> Pointer to the patch?
>
> For better or for worse, I have created a patch against the py3k trunk
> which introduces a binary operator '@' as an alternative syntax for
> the new string formatting system introduced by PEP 3101 ("Advanced
> String Formatting"). [1]
I'd like to join everybody else who said that this would be
Ah, the people have spoken!
On Sun, Jun 21, 2009 at 2:12 PM, Terry Reedy wrote:
> The place to float trial balloons is the python-ideas list.
I'll put this one to rest, and as mentioned, will direct any future
suggestions to python-ideas instead of here.
Most of the arguments against my proposal
To All,
It appears that one possibility of investigation into the development of a
safety-critical variant of the python language would be to conduct run time
error analysis of the source code that is responsible for producing the python
language. Therefore, I will now conduct these run t
Jerry Chen wrote:
Hello all,
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 ("Advanced
String Formatting"). [1]
For common cases, this syntax shoul
On Sun, 21 Jun 2009 at 12:36, Jerry Chen wrote:
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 ("Advanced
String Formatting"). [1]
It seems to me t
Hello,
> For better or for worse, I have created a patch against the py3k trunk
> which introduces a binary operator '@' as an alternative syntax for
> the new string formatting system introduced by PEP 3101 ("Advanced
> String Formatting"). [1]
While many people find the new format() tedious to
On Sun, Jun 21, 2009 at 1:36 PM, Jerry Chen wrote:
> QUICK EXAMPLES
>
> >>> "{} {} {}" @ (1, 2, 3)
> '1 2 3'
>
> >>> "foo {qux} baz" @ {"qux": "bar"}
> 'foo bar baz'
>
> One of the main complaints of a binary operator in PEP 3101 was the
> inability to mix named and unnamed arguments:
>
Hello all,
For better or for worse, I have created a patch against the py3k trunk
which introduces a binary operator '@' as an alternative syntax for
the new string formatting system introduced by PEP 3101 ("Advanced
String Formatting"). [1]
For common cases, this syntax should be as simple and a
17 matches
Mail list logo
