> In the meantime (thinking out loud here), would it be possible to keep
> search engines from seeing a submission or an edit until a trusted person
> has had a chance to approve it?
It would be possible, but I would strongly oppose it. A bug tracker
where postings need to be approved is just unac
>> Now it's up to volunteers to do ongoing spam clearing, and we don't
>> have that much volunteers. I think a single-click button "Spammer"
>> should allow committers to lock an account and hide all messages and
>> files that he sent, but that still requires somebody to implement
M.-A. Lemburg wrote:
> * non-ASCII code points in text are not uncommon, they occur
> in most European scripts, all Asian scripts,
In an Asian script, almost every character is likely to
be non-ascii, which is going to be pretty hard to read
as a string of unicode escapes.
Maybe what we want is
Patch / Bug Summary
___
Patches : 362 open ( +2) / 3766 closed ( +6) / 4128 total ( +8)
Bugs: 968 open ( -3) / 6692 closed ( +9) / 7660 total ( +6)
RFE : 256 open ( -1) / 286 closed ( +4) / 542 total ( +3)
New / Reopened Patches
__
Fix off-b
Joe Eagar wrote:
> Hi I'm getting extremely odd behavior. First of all, why isn't
> PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's
> python integration (it embeds python, as opposed to python embedding
> it). I have a function that executes a string buffer of python code,
Hi I'm getting extremely odd behavior. First of all, why isn't
PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's
python integration (it embeds python, as opposed to python embedding
it). I have a function that executes a string buffer of python code,
fetches a function from
On 2007-05-13 18:04, Martin v. Löwis wrote:
>> * without the Unicode escapes, the only way to put non-ASCII
>> code points into a raw Unicode string is via a source code encoding
>> of say UTF-8 or UTF-16, pretty much defeating the original
>> requirement of writing ASCII code only
>
> That'
"Joe Eagar" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| why isn't PyEval_EvalCode documented anywhere?
Most likely just overlooked and never reported. See Appendix A of the
Python/C API
http://docs.python.org/api/reporting-bugs.html
If you make a report, please provide a l
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> I don't understand the point of a "security release" made up to a year
| > after commit, especially in view of the first quoted paragraph.
A security release is presumably a response to a serious problem.
| I thi
On Sun, May 13, 2007, Joe Eagar wrote:
>
> Hi I'm getting extremely odd behavior. First of all, why isn't
> PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's
> python integration (it embeds python, as opposed to python embedding
> it). I have a function that executes a strin
Hi I'm getting extremely odd behavior. First of all, why isn't
PyEval_EvalCode documented anywhere? Anyway, I'm working on blender's
python integration (it embeds python, as opposed to python embedding
it). I have a function that executes a string buffer of python code,
fetches a function from
> I don't understand the point of a "security release" made up to a year
> after commit, especially in view of the first quoted paragraph.
The objective is to reduce load for the release manager. Any kind of
release that is worth anything takes several hours to produce, in
my experience (if it c
On 5/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Now it's up to volunteers to do ongoing spam clearing, and we don't
> have that much volunteers. I think a single-click button "Spammer"
> should allow committers to lock an account and hide all messages
> and files that he sent, but that s
"tomer filiba" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> why not add __enter__ and __exit__ to generator objects?
> it's really a trivial addition: __enter__ returns self, __exit__ calls
> close().
> it would be used to ensure close() is called when the generator is
> disposed, inste
> * without the Unicode escapes, the only way to put non-ASCII
> code points into a raw Unicode string is via a source code encoding
> of say UTF-8 or UTF-16, pretty much defeating the original
> requirement of writing ASCII code only
That's no problem, though - just don't put the Unicode ch
On Sun, May 13, 2007 at 04:56:15PM +0200, tomer filiba wrote:
>why not add __enter__ and __exit__ to generator objects?
>it's really a trivial addition: __enter__ returns self, __exit__ calls
>close().
>it would be used to ensure close() is called when the generator is
>disposed
why not add __enter__ and __exit__ to generator objects?
it's really a trivial addition: __enter__ returns self, __exit__ calls
close().
it would be used to ensure close() is called when the generator is disposed,
instead of doing that manually. typical usage would be:
with mygenerator() as g:
On 2007-05-12 02:42, Andrew McNabb wrote:
> On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote:
>> I wonder how we managed to survive all these years with
>> the existing consistent and concise definition of the
>> raw-unicode-escape codec ;-)
>>
>> There are two options:
>>
>> * no one
> I clicked on the tracker link out of curiosity noticed that the
> tracker has been spammed -- issues 1028, 1029 and 1030 are all spam
> (1028 seems a test by the spammer).
>
> These issues should be deleted and their creator's accounts disabled.
(Notice that the spammer hasn't been as successfu
19 matches
Mail list logo
