Gustavo Carneiro schrieb:
>What about http://www.python.org/sf/1564547 ? It tries to solve a
> different problem, but I think it also fixes this one; at least as much
> as possible with the braindead unix signal programming interface...
I'm sceptical. It is way too much code for me to review,
Brett Cannon schrieb:
> I am trying to commit to the 2.5 branch and I am getting an error:
>
> svn: Commit failed (details follow):
> svn: Can't create directory
> '/data/repos/projects/db/transactions/53566-1.txn': Permission denied
>
> Anyone know what is going on?
It's not clear to me. The pe
Nick Maclaren schrieb:
>> I personally consider *very* important that hash(5.0) == hash(5) (and
>> that 5.0 == 5, of course).
>
> It gets a bit problematic with floating-point, when you can have
> different values "exactly 5.0" and "approximately 5.0". IEEE 754
> has signed zeroes. And so it goe
Greg Ewing schrieb:
>> Please
>> try to come up with a patch (e.g. by putting a while(is_tripped) loop
>> around the for loop).
>
> That isn't going to fix it.
Why not?
> What's needed is to somehow
> atomically test and clear is_tripped at the beginning.
How would that help? The case in quest
Kristján V. Jónsson schrieb:
> We have been using gc.get_objects() but it has several problems:
> 1) It returns all objects in the system.
Actually, it doesn't. It only returns objects that participate
in cyclic GC (i.e. container objects).
> 2) There is no way to frame certain operations and get
Tim Peters schrieb:
>> Does that mean that they are unstable, in the sense that they may
>> change behaviour in new versions of Python?
>
> They /may/ change, but they won't (== only common sense guarantees
> they won't change ;-)).
That, of course, is true for any API. For the documented API, th
Greg Ewing schrieb:
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
Ok, I'm correcting you: This is not what the current
method does:
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> i
Nick Maclaren schrieb:
For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0
>>> Unfortunately, that assumes that equality is transitive.
>> No, but the (transitively closed set of equivalent objects) must have
>> the same hash. ...
>
> Er, how do you have a transitive closure for a non-transiti
Nick Maclaren schrieb:
>> If so, they just shouldn't use the equal operator (==). == ought to
>> be transitive. It should be consistent with has().
>
> Fine. A very valid viewpoint. Would you like to explain that to
> the IEEE 754 people?
Why should I? I don't talk about IEEE 754, I talk about
Fabio Zadrozny schrieb:
> Would it be ok to add a feature request for that?
Nobody can stop you, anyway :-)
Seriously, a feature request is likely to sit there
forever. If you would come up with an actual patch,
that would be a different thing. You'll likely answer
your other question in the pro
#1653736 reports that slot_nb_inplace_power has the wrong
type: it should be a ternary function, but only is a binary.
The proposed change is to make it ternary, and to invoke __ipow__
with three arguments.
In researching this, I came to wonder why nb_inplace_power is
ternary in the first place. I
[EMAIL PROTECTED] schrieb:
1. For 2.5.1, rewrite slot_nb_inplace_power to raise an exception
if the third argument is not None, and then invoke __ipow__ with only one
argument.
>
> Why would you change Py2.5? There is no bug here.
There is: slot_nb_inplace has the signature
stat
Brett Cannon schrieb:
> Seems reasonable to me. Is the argument of None passed in
> automatically somewhere?
There are few callers of nb_inplace_power at all (AFAICT, only
PyNumber_InPlacePower); in turn, PyNumber_InPlacePower is called
with the implicit Py_None always:
- ceval.c, for INPLACE_P
Raymond Hettinger schrieb:
> That made sense, but my question was whether there would be benefit
> to making the change in the middle of a major release. At worst, code
> that is
> currently working due to undefined behavior will stop working. I don't
> see any offsetting benefit. ISTM that Py
Greg Ewing schrieb:
> Might we want to add an in-place version of the 3-arg
> pow() function one day? If so, leaving the third argument
> there could be useful.
What could the syntax for that be?
Instead of writing
x = pow(x, n, 10)
would you write
x pow n = 10
? or perhaps
x ** n = 10
or
x
Guido van Rossum schrieb:
> I recently needed to access an HTTP URL with a timeout. I ended up
> monkey-patching httplib.HTTPConnection so that the connect() method
> has an optional second paramer, timeout, defaulting to None; if not
> None, a call to settimeout() is added right after successful c
Greg Ewing schrieb:
>> What could the syntax for that be?
>
> It wouldn't be a syntax, just a function, e.g.
>
>ipow(x, n, 10)
In what way would that be inplace? A function cannot
rebind the variables it gets as parameters.
Regards,
Martin
___
Pyt
Jim Jewett schrieb:
> Either
>
> x**= n % 10 # The **= changes the parse context, so that %
> is no longer
> # immediately evaluated
Are you seriously proposing such a change? I was asking for
spellings that currently don't have a meaning (rather, I was
[EMAIL PROTECTED] schrieb:
> Guido> I'm not going to change ftplib.py and all the others.
>
> Also understood. This has, as far as I know, been the response of everybody
> who has encountered this problem before.
You should read your SF bug list more frequently, then. You are
currently as
[EMAIL PROTECTED] schrieb:
> I don't know if feature requests for Roundup are still being accepted, but I
> hope one of its features is that it can remind people periodically of the
> tickets they own. My primary goal in life is not to close Python bugs and
> patches, so I hope people will underst
Brett Cannon schrieb:
>> Of course Stackless isn't quite fully integrated with 2.5 (yet).
>>
>> When did someone last suggest that Stackless become part of the core
>> CPython implementation, and why didn't that ever happen?
>>
>
> Don't remember the "when". The "why" has always been that Christi
Richard Tew schrieb:
> If these generator coroutine microthreads went ahead and part
> of it was improving the support for asynchronous calls in the
> runtime and standard library, this would also be something
> which also benefited Stackless Python. Even if they didn't go
> ahead I would be inter
Brett Cannon schrieb:
> On 2/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Someone checked in Parser/Python.asdl. After rebuilding Subversion tells me
>> that Python/Python-ast.c has been modified. I assume the two are related.
>> Did whoever checked in the former need to check in the la
Armin Rigo schrieb:
> The history as I remember it is that Christian tried hard to integrate
> the first versions of Stackless with CPython, but was turned town by
> python-dev.
Are there public records of that? As I remember it, Christian never
actually submitted a patch for inclusion (at least n
Guido van Rossum schrieb:
> Is this documented somewhere? It wouldn't hurt if there was a pointer
> to that documentation right next to the line in Python-ast.c that gets
> modified by the regeneration. (I've been wondering about this a few
> times myself.)
Done!
Martin
_
Brett Cannon schrieb:
> /*
> File automatically generated by %s.
>
> This module must be committed separately from each AST grammar change;
> the __version__ number is set to the revision number of the commit
> containing the grammar change.
> */
It doesn't completely show up in "svn diff
Anthony Baxter schrieb:
>>This module must be committed separately from each AST grammar
>> change; the __version__ number is set to the revision number of
>> the commit containing the grammar change.
>> */
>
> Note that the welease.py script that builds the releases does
> a "touch" on the r
Martin v. Löwis schrieb:
> Guido van Rossum schrieb:
>> Is this documented somewhere? It wouldn't hurt if there was a pointer
>> to that documentation right next to the line in Python-ast.c that gets
>> modified by the regeneration. (I've been wondering about this a
Richard Tew schrieb:
> I can't point you to the posts, but I can point you to something
> Christian has written on the subject which may indicate why
> it was never actually submitted for inclusion.
>
> See "A Bit Of History"
> http://svn.python.org/view/stackless/trunk/Stackless/readme.txt
>
> I
Guido van Rossum schrieb:
> PS Thanks to Ben for excellent summaries of the discussion so far!
I'd like to second this. This is how PEPs ought to work.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
Richard Tew schrieb:
> It depends what you mean by mechanism. I can't go into low level details
> because I do not have the necessary experience or knowledge to know
> which approach would be best.
Indeed, low-level details is what I'm interested in.
> I currently use Windows. By using asyncore
Mike Klaas schrieb:
>> cause problems for other users of the interned string. I agree with the
>> reasoning, but propose a different solution: when interning an instance
>> of a string subtype, PyString_InternInPlace could simply intern a copy.
>
> Interning currently requires an external referen
Hrvoje Nikšić schrieb:
> The patch could look like this. If there is interest in this, I can
> produce a complete patch.
I can't see a problem with that (although I do wonder why people create
string subtypes in the first place).
Regards,
Martin
___
P
Greg Ewing schrieb:
> The other thing is that, even if some kind of migration
> path could be found, Guido et al wouldn't want to follow
> that path anyway -- because the end result would be too
> convoluted for ordinary people to understand and maintain.
That very much depends on what the end res
Brett Cannon schrieb:
> name = 'open_' + urltype
> self.type = urltype
> name = name.replace('-', '_')
> if not hasattr(self, name):
> if proxy:
> return self.open_unknown_proxy(proxy, fullurl, data)
> else:
> r
Ron Adam schrieb:
> I think it's gets a bit awkward in some situations.
>
>
> if bar->'__%s__' % attr < -42: print 'Hello World'
>
> if bar.['__%s__' % attr] > -42: print 'Hello World'
>
>
> To me it's easier to parse the second one visually.
Ah, precedence.
It definitly should be a
Collin Winter schrieb:
> 1) There are times when the _fields attribute on some AST nodes is
> None; if this was done to indicate that a given node has no
> AST-related attributes, it would be much easier if _fields was [] in
> this case. As it is, I had to special-case "node._fields is None" in
> t
Hrvoje Nikšić schrieb:
> Another reason is that Python's interning mechanism is much better than
> such a simple implementation: it stores the interned state directly in
> the PyString_Object structure, so you can find out that a string is
> already interned without looking it up in the dictionary.
Georg Brandl schrieb:
>
>> a.([b])
> No. (you can't write a([b]) today)
Actually, you can, but it means something
>
>> a . [ b ]
> Yes. (you can write a . b today)
OTOH, you can't write
x + = 2
or
a = 2 * * 4
so it's not that obvious that .[ should be two tokens.
Regards,
M
Steve Holden schrieb:
> The only things that concern me are a) whether it could make sense to
> add Stackless in bits and pieces and b) whether the BDFL (or even the
> developer community en masse) would object in principle, thereby
> rendering such efforts useless.
I think I need to try again.
Greg Ewing schrieb:
> That doesn't quite give you everything that real interning
> does, though. The string comparison method knows when both
> strings are interned, so it can compare them quickly
> whether they are equal or not.
No, it doesn't - see stringobject.c:string_richcompare.
If they ar
Grig Gheorghiu schrieb:
> So is there any value or interest in setting up a svn notification
> hook for py3k commits that would go to the pybots buildbot master?
A similar question is whether there should be buildbots for Python 3
itself (i.e. running the test suite). Even for that, it was conside
Richard Tew schrieb:
> If there is no Stackless 'hard switching' available (the stack
> switching done with assistance of assembler) for the platform it is
> being compiled on, then compilation proceeds without Stackless
> compiled into Python. The module is not available. The process
> of adding
Anthony Baxter schrieb:
>> and the "wrapper class" idea of Nick Coghlan:
>>attrview(obj)[foo]
>
> This also appeals - partly because it's not magic syntax
I also like this. I would like to spell it attrs, and
I think its specification is
class attrs:
def __init__(self, obj):
self.ob
Ron Adam schrieb:
> Would it be possible for attrview to be a property?
Sure. It might conflict with a proper name of an attribute, of course.
> Something like... (Probably needs more than this to handle all cases.)
>
> class obj(object):
> def _attrview(self):
> retu
Mike Klaas schrieb:
> The entire codebase was developed post-2.4
Can you find out what percentage of these could have used
a __getitem__ if it had been implemented? As a starting
point, count all 'getattr(self' invocations.
Regards,
Martin
___
Python-De
Greg Ewing schrieb:
> It's certainly possible to tell very easily whether
> a string is interned -- there's a PyString_CHECK_INTERNED
> macro that tests a field in the string object header.
> But, I can't find anywhere that it's used in the core,
> apart from the interning code itself and the strin
Greg Ewing schrieb:
> Brett Cannon wrote:
>> On 2/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>>> 2) {BinOp,AugAssign,BoolOp,etc}.op
>> I can't think of a reason, off the top of my head, why they can't be
>> singletons.
>
> Why not just use interned strings?
Because it's generated code. It ha
Collin Winter schrieb:
> 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already
> singleton instances of their respective classes. I've changed
> asdl_c.py to no longer emit the *_singleton names and to use the
> corresponding *_type types in their place, which will enable me to
> writ
Greg Ewing schrieb:
> It would seem even easier (and a lot faster) to use an
> array to go from C enum --> some object, which could
> as well be an interned string as anything else.
Have you actually looked at the code? How could it be
faster than
PyObject* ast2obj_boolop(boolop_ty o)
{
Thomas Wouters schrieb:
>
> The same way += et al. are in-place: it would ask 'x' to modify itself,
> if it can. If not, no harm done. (It would be called as 'x = ipow(x, n,
> 10)' of course, just like 'x += n' is really 'x = x.__iadd__(n)')
I think this would violate the policy that a mutating
Thomas Wouters schrieb:
>
> Sure, and I don't know if anyone will ever want ipow() -- but I've never
> seen real code use the three-argument pow() either. The fact is that all
> the in-place modifying hooks return the result (which may or may not be
> self, and may or may not be mutated) so an
Larry Hastings schrieb:
> If I understand your question correctly, you're saying "why doesn't
> string comparison take advantage of interned strings?" If so, the
> answer is "it does". Examine string_richcompare() in stringobject.c,
> and PyUnicode_compare() in unicodeobject.c. Both functions
Collin Winter schrieb:
> What's inconsistent about it? That classes are being used for the
> _ast.{Add,Sub,Mult,etc} names?
Exactly. These aren't names - they are nodes in the tree. All nodes
are instances of _ast.AST.
> I don't see the need for both _ast.Add and _ast.Add.singleton or
> _ast.add
Thomas Wouters schrieb:
> If all (or all-but-one) of them have a 'run one iteration' method, you
> can call that from the 'main' mainloop.
That doesn't really work (and neither do variations involving coroutines.
Either the 'run one iteration' method blocks until one even arrives,
in which case
Greg Ewing schrieb:
> On unix at least, I don't think it should be necessary
> to change gtk, only pygtk. If it can find out the file
> descriptor of the connection to the X server, it can
> plug that into the reactor, and then call
> gtk_main_iteration_do() whenever something comes in
> on it.
Th
[EMAIL PROTECTED] schrieb:
> Asyncore *only* implements asynchronous IO -- any "tasks" performed in
> its context are the direct result of an IO operation, so it's hard to
> say it implements cooperative multitasking (and Josiah can correct me if
> I'm wrong, but I don't think it intends to).
I'm
Larry Hastings schrieb:
> Bob Ippolito wrote:
>> There is no single PerfectReactor. There are several use cases where
>> you need to wait on >1 different event systems, which guarantees at
>> least two OS threads (and two event loops). In general it's nice to
>> have a single Python event loop ("th
Larry Hastings schrieb:
> Oof! I'm embarrassed to have forgotten that. But that's not a fatal
> problem. It means that on Windows the PerfectReactor must service the
> blocking GetMessage loop, and these other threads notify the
> PerfectReactor of new events by sending a message.
...
> I'd
Raymond Hettinger schrieb:
> No need to go so widely off-track. The idea is to have an efficient type
> that
> is directly substitutable for tuples but is a bit more self-descriptive. I
> like
> to have the doctest result cast at NamedTuple('TestResults failed attempted).
> The repr of that
Nick Coghlan schrieb:
>> I'd like to repeat Guido's question: Why does this still need to
>> support the tuple interface (i.e. indexed access)?
>
> So that it remains interoperable with existing libraries that expect a
> tuple? Otherwise you'd be casting (and copying) every time you needed to
>
Nick Coghlan schrieb:
> However, another aspect that occurred to me is that inheriting from
> tuple has significant practical benefits in terms of speed and memory
> consumption, at which point it doesn't seem worthwhile to *remove* the
> indexing capability.
I'm not so sure that inheriting fro
Oleg Broytmann schrieb:
>That changes the meaning, but... have you ever tried to ride a horse
> designed by a group of Clever Individuals loosely connected by email? ;) I
> am afraid of even thinking of its ugliness and speed. (-:
>I think a committee is better than nothing, and I believe C
Raymond Hettinger schrieb:
> d, g, v, t, r = model(somecontract)
I find that line quite unreadable, and find it likely that I would
not be able to remember the standard order of the fields.
You almost "had me" with the two fields example, but this makes
me think "-1" again.
Is it really that you
Derek Shockey schrieb:
> Since I was writing a script to work with potentially very large zipped
> files, I took it upon myself to write an extract() method for zipfile,
> which is essentially an adaption of the read() method modeled after
> tarfile's extract(). I feel that this is something tha
Collin Winter schrieb:
> But Pass, Break, Continue and Ellipsis aren't in the same category as
> Add, Mult, Div, etc.. The former stand alone
That's not true. Pass, Break, Continue don't stand alone; they are
members of the body sequence of some other statement (in particular
for Break and Contin
KoDer schrieb:
> open("/usr/lib/python2.4/site-packages/Durus-3.6-py2.4-linux-i686.egg",
> O_RDONLY|O_LARGEFILE) = 6
> ..
> _llseek(6, 98304, [98304], SEEK_SET)= 0
> read(6, "\340\377\224\322\373C\200\177.\245\367\205\0\307x\207\r"...,
> 4096) = 4096
> _llseek(6, 102400, [102400], SEEK_SET)
Patch #1648268 corrects a huge load of errors in Python wrt.
incorrect function pointers (i.e. functions called with a
different signature then declared, through pointers).
The rationale for this patch is that the submitter apparently
has a platform where Python crashes in the face of these errors.
Raymond Hettinger schrieb:
> If I'm understanding what was done for dictionaries, the hash table can grow
> larger than the range of hash values. Accordingly, I would expect large
> dictionaries to have an unacceptably large number of collisions. OTOH, we
> haven't heard a single complaint, so
Fredrik Lundh schrieb:
>> My suspicion is that building Python for an 64-bit address space is
>> still a somewhat academic exercise.
>
> arbitrary 64-bit systems, perhaps. the first Python system I ever built was
> deployed
> on an LP64 system back in 1995. it's still running, and is still bein
Neal Becker schrieb:
> Doesn't this seem a bit inconsisent?
Please don't ask such questions. Instead, formulate them as
"I would have expected the result to be X instead. Why is
the result Y?" (if that is actually the question you meant
to ask)
IOW, what does it help you if somebody answers "yes"
Greg Ewing schrieb:
> But bool isn't really a numeric type in the same way
> that the others are. It's only a subtype of int for
> historical reasons. If it had been a part of Python
> from the beginning, it probably would have been a
> separate type altogether.
>
> Hmmm... is that something that
Hans Meine schrieb:
> For a long time, I have been annoyed by distutils behavior concerning
> "scripts": I always put
> #!/usr/bin/env python
> into the first line in order to let the incredibly useful "env" program start
> the right python version.
>
> I know that it is quite evil to hardco
Hans Meine schrieb:
> (I first posted this to distutils-sig but was told that distutils is a bit
> neglected there, so I decided to try to push these simple patches in via
> python-dev.) Lately, a student came to me complaining about an old distutils
> bug which
> bit him:
> http://mail.pyt
Greg Ewing schrieb:
>> One idiom that people use a lot is foo[b], where
>> b is a boolean.
>
> Could that be addressed using the new __index__ mechanism?
That would be possible, yes.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
Thomas Wouters schrieb:
> My only objection (which is a minor one) is with the 'NOARGS_NULL' name.
> Caps don't fit the normal style rules, and 'noargs_null' doesn't make
> much sense to me. 'unused' strikes me as a clearer name (or
> 'noargs_unused' or 'args_unused' or such.)
The point clearly i
Mateusz Rukowicz schrieb:
> Last holidays I was writting C decimal during summer of code 2006, I
> planned to take a breath for 1-2 months and then continue work, but
> well, things didn't go the way I planned. Now I am ready to continue
> work, I mainly plan to optimize it a little bit (top pri
Joseph Armbruster schrieb:
> The -U option was added back in 2000, rev 15296 and mention of it was
> removed
> in rev 25288. Should the -U option still be handled from the command line?
Yes. The original goal of the -U command line (find out what happens
if all strings were unicode) still remains
K D schrieb:
> I thought it would be nice to have the code marked somehow so that it
> was obvious what the additional (and obviously unused) parameter was.
> The two references (NULL and METH_NOARGS) are both in upper-case and as
> C is a case-sensitive language I think it's probably usual to do
>
Chris AtLee schrieb:
> I just got bitten by the runtime library incompatibility problem on
> windows when I tried to load a C extension compiled with MSVC 2005
> (64-bit) into Python 2.5.
>
> I realize that Python2.5 will continue to use MSVC 2003 for
> compatibility reasons, but I was curious if
Chris AtLee schrieb:
>> I would guess it is more an issue of 32bit + 64bit dynamic linking
>> having issues, but I could certainly be wrong.
>
> I don't think so, this was the 64bit version of Python 2.5. When I
> recompiled with the 2003 compiler it worked fine.
Again, what 2003 compiler did yo
Jack Diederich schrieb:
> __ Parser/Python.asdl may need changes to match the Grammar.
>Use Parser/asdl_c.py to regenerate Include/Python-ast.h
On Unix, make will automatically run it when Python.asdl changes.
> __ Python/Python-ast.c may need changes to create the AST
>ob
Facundo Batista schrieb:
> The question is what to do when we found a question in a code. Reading
> urllib2 I found:
>
> # XXX why does self.handlers need to be sorted?
>
> I found the answer, so I deleted that line, and added a comment in that
> place just to clarify.
>
> Shall I do somethin
David Abrahams schrieb:
> I tried building with MS Visual Studio 2005 from PCBuild8/pcbuild.sln,
> and for me it fails miserably. The first major complaint comes when
> linking pythoncore, where the _init_types symbol can't be found. On
> the other hand, allowing MSVS to convert PCBuild/pcbuild.s
Andrew MacKeith schrieb:
> Is there a scheduled date for the release of Python-2.5.1 ?
There was a scheduled date, but it then interfered with the schedule
of the people executing it, so there is none at the moment. I think
we will release 2.5.1 in April.
> I presume that the PCBuild8 directory s
Eric V. Smith schrieb:
> I'm working on PEP 3101, Advanced String Formatting. About the only
> built-in numeric formatting I have left to do is for converting a
> PyLongOjbect to binary.
>
> I need to know how to access the bits in a PyLong.
I think it would be a major flaw in PEP 3101 if yo
A.M. Kuchling schrieb:
> FWIW, I have a related perception that we aren't getting new core
> developers. These two problems are probably related: people don't get
> patches processed and don't become core developers, and we don't have
> enough core developers to process patches in a timely way. An
Phil Thompson schrieb:
> 1. Don't suggest to people that, in order to get their patch reviewed, they
> should review other patches. The level of knowledge required to put together
> a patch is much less than that required to know if a patch is the right one.
People don't *have* to review patches
[EMAIL PROTECTED] schrieb:
> The patches list really ought to be _this_ list. The fact that it isn't
> is indicative of a failure of the community.
I disagree that python-dev isn't the patches list. People often discuss
patches here (although much discussion is also in the tracker).
> One worr
Phil Thompson schrieb:
> I'm not sure what your point is. My point is that, if you want to encourage
> people to become core developers, they have to have a method of graduating
> through the ranks - learning (and being taught) as they go. To place a very
> high obstacle in their way right at th
Phil Thompson schrieb:
>>> Any ideas for fixing this problem?
>> A better patch-tracker, better procedures for reviewing patches surounding
>> this new tracker, one or more proper dvcs's for people to work off of. I'm
>> not sure about 'identifying core developers' as we're all volunteers, with
>>
Neil Schemenauer schrieb:
> I guess Andrew was looking for specific instructions. Install git
> and git-svn. For Debian stable, you can get them from
> http://backports.org/debian/pool/main/g/git-core/.
>
> Initialize the repository:
>
> git-svn init http://svn.foo.org/project/trunk
>
> Fe
Collin Winter schrieb:
> It would also be helpful to have some loose guidelines/requirements
> for how to become a module maintainer (e.g., "we're looking for the
> following traits...").
That is easy to answer: Review the patches of the module, and post
a message to python-dev about your findings
Scott Dial schrieb:
> While I understand that this tit-for-tat mechanism is meant to ensure
> participation, I believe in reality it doesn't, as the 400-some
> outstanding patches you referenced elswhere indicate. I can personally
> attest to having a patch that is over a year old with no "core
Raymond Hettinger schrieb:
> [Phil Thompson]
>> I think a lot of people care, but many can't
>> do anything about because the barrier to entry is too great.
>
> Do you mean commit priviledges? ISTM, those tend to be
> handed out readily to people who assert that they have good use for them.
> As
Stephen J. Turnbull schrieb:
> An informal version of this process is how XEmacs identifies its
> Reviewers (the title we give to those privileged to authorize commits
> to all parts of XEmacs). People who care enough to make technical
> comments on *others'* patches are rare, and we grab the comp
Phil Thompson schrieb:
>>> 2. Publically identify the core developers and their areas of expertise
>>> and responsibility (ie. which parts of the source tree they "own").
>> I doubt this will help. Much of the code isn't owned by anybody
>> specifically. Those parts that are owned typically find t
Phil Thompson schrieb:
>> And please be assured that no such obstacle is in the submitters way.
>> Most patches are accepted without the submitter actually reviewing any
>> other patches.
>
> I'm glad to hear it - but I'm talking about the perception, not the fact.
> When
> occasionally submitte
Phil Thompson schrieb:
>>> Of course it's not unreasonable. I would expect to be told that a patch
>>> must have tests and docs before it will be finally accepted. However,
>>> before I add those things to the patch I would like some timely feedback
>>> from those with more experience that my patch
Phil Thompson schrieb:
> My point is simply that the effort required to review patches seems to be a
> problem. Perhaps the reasons for that need to be looked at and the process
> changed so that it is more effective. At the moment people just seem be
> saying "that's the way it is because that'
1901 - 2000 of 5277 matches
Mail list logo
