Bill Janssen wrote:
Yeah, but you can't do more complicated expressions that way, like
any(lambda x: x[3] == thiskey)
Not /quite/ sure what this is intended to mean, but most likely,
you meant
any(x[3]==thiskey for x in seq)
I think it makes a lot of sense for any and all to
Tim Peters wrote:
Because new-style classes create cycles that Py_Finalize() doesn't
clean up, it may make analysis easier to stick a PyGC_Collect() call
(or two! repeat until it returns 0) inside the loop now.
I'm shy to do this: the comment in Py_Finalize suggests that things
will break if
Tim Peters wrote:
Since we're spread across time zones, I think 24 hours is a good
minimum.
Ok, done.
If something is set to 12 hours now, doesn't look like it's
working: when I wrote my msg, it showed (as I said) about 5 hours of
history. Right now it shows only about 3 hrs, from Sat 15
Brett Cannon wrote:
Basically, from all the replies I have gotten has said that package
that were/are externally maintained either considers Python HEAD as
the current version or watches checkins and the bug tracker and thus
the PEP is really not needed. So unless some package steps forward
Tim Peters wrote:
Putting a collection call inside an initialize/finalize loop isn't
doing it late, it's doing it early. If we can't collect cyclic trash
after Py_Initialize(), that would be a showstopper for apps embedding
Python in a loop! There's either nothing to fear here, or Python
Neal Norwitz wrote:
If the patch won't fix the problem, is there something else we can do
to ensure the python DLL is no longer used regardless of whether the
previous test passed or not?
Rebooting the machine will help, and might be the only cure.
It's Windows, after all :-(
Of course, we
Tim Peters wrote:
2. The buildbot code tries to kill the process itself. It appears (to judge
from the buildbot messges) that this never works on Windows.
3. For reasons that are still unknown, python_d.exe keeps running,
and forever.
It's actually not too surprising that
David Abrahams wrote:
I just wanted to write to encourage some Python developers to look at
(and accept!) Christoph's patch. This is really crucial for smooth
interoperability between C++ and Python.
I did, and accepted the patch. If there is anything left to be done,
please submit another
Currently, the readdir() call releases the GIL. I believe
this is not thread-safe, because readdir() does not need
to be re-entrant; we should use readdir_r where available
to get a thread-safe version.
Comments?
Regards,
Martin
___
Python-Dev mailing
Ronald Oussoren wrote:
AFAIK readdir is only unsafe when multiple threads use the same DIR* at
the same time. The spec[1] seems to agree with me.
[1] : http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html
What specific sentence makes you think so? I see
The readdir() interface
OTOH, we could just as well check in an executable that
does all that, e.g. like the one in
I did something like this: I checked the source of a
kill_python.exe application which looks at all running processes
and tries to kill python_d.exe. After several rounds of
experimentation, this now was
Grégoire Dooms wrote:
What should I do to get it reviewed further ? (perhaps just this :
posting to python-dev :-)
It didn't help that much, except for keeping your mail in my inbox.
In any case, I went back to it and checked it in.
Regards,
Martin
Peter Moore wrote:
I'm responsible for setting up free FishEye hosting for community
projects. As a long time python user I of course added Python up
front. You can see it here:
http://fisheye.cenqua.com/viewrep/python/
Can you please move that to the subversion repository
Anthony Baxter wrote:
There's a scripts Tools/scripts/reindent.py - put it somewhere on your
PATH and run it before checkin, like reindent.py -r Lib. It means Tim
or I don't have to run it for you wink
As I kept forgetting what the name, location, and command line options
of that script are, I
Ronald Oussoren wrote:
A couple of lines down it says:
The pointer returned by readdir() points to data which may be
overwritten by another call to readdir() on the same directory
stream. This data is not overwritten by another call to readdir() on
a different directory stream.
This
Tim Peters wrote:
No, what's surprising is that it keeps running _forever_. This isn't
Unix, and, e.g., a defunct child process doesn't sit around waiting
for its parent to reap it. Why doesn't the leftover python_d.exe
complete running the test suite, and then go away all by itself? It
[EMAIL PROTECTED] wrote:
if (b == 1) {
-literal = sre_literal_template(ptr, n);
+ literal = sre_literal_template((SRE_CHAR *)ptr, n);
} else {
#if defined(HAVE_UNICODE)
-literal = sre_uliteral_template(ptr, n);
+
[EMAIL PROTECTED] wrote:
Martin Also, I suggest to use None as the return value for no value
Martin available; it might be that the configured value is an empty
Martin string (in which case confstr returns 1).
I'll work on all of this. Are you sure you want the API to change?
Fredrik Lundh wrote:
it's still listed under possible additions in the release PEP, and there
don't
seem to be a PEP or any other easily located document that explains exactly
how it works, what's required from library developers, how it affects existing
toolchains, etc. is this really
Gerhard Häring wrote:
Speaking of which, what about SVN commit privileges for me?
Send me your key, and I'll add you. I assume 'gerhard.haering'
would work as the commit name?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing wrote:
I started refactoring some of the ugliness out of the internals of
distutils last year, but was completely stymied by the demand that no
existing setup.py scripts be broken.
Instead of trying to fix distutils, maybe it would be better
to start afresh with a new package
Anthony Baxter wrote:
It is *precisely* my concern that this happens. For whatever
reason, writing packaging-and-deployment software is totally
unsexy. This is why setuptools is a one-man show, and this is why
the original distutils authors ran away after they convinced
everybody that
Anthony Baxter wrote:
And I would reply that sometimes a rewrite is necessary. I doubt
firefox would be at the state it is today if it was still based on
the ancient netscape codebase.
It's off-topic here certainly: but firefox is actually not a complete
rewrite; it still has tons of
Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
I see a significant procedural difference between what happened
for ctypes, elementtree, and
Anthony Baxter wrote:
And now let's look at some of the stuff that setuptools gives us:
- We have a CPAN-type system
I think it is unfair (to Richard Jones) to attribute this to
setuptools. We already have a CPAN-type system: the Cheeseshop.
What setuptools adds is roughly the CPAN shell
Greg Ewing wrote:
I'm not sure whether distutils is really that
badly broken. But an earlier poster seemed to be
saying that he had great difficulty finding anything
that could be changed without breaking something
that someone relied on. It's hard to fix something
if you can't change it at
Phillip J. Eby wrote:
I assumed that it would be more controversial to merge setuptools into
distutils, than to provide it as an enhanced alternative.
It is this assumption in setuptools that seems to have guided many
design decisions: that it is completely unacceptable to change
I don't understand it.
Have you read the manuals?
You mean,
http://peak.telecommunity.com/DevCenter/setuptools
Yes, I did. However, this would only enable me to use it (should I
ever find a need). What I really need to understand is how all this
stuff works inside.
Now, I haven't actually
Anthony Baxter wrote:
Not without a lot of the other stuff that's in setuptools.
That is says from itself that it is version 0.7a1dev-r45536
doesn't help to reduce that fear.
It's had _two_ _years_ of quite active development, so the version
number of 0.7 is hardly a good indication. As
Fredrik Lundh wrote:
you do wonderful stuff, and then you post the announcement as a
followup to a really old message, to make sure that people using a
threaded reader only stumbles upon this by accident... this should
be on the python.org frontpage!
I also wonder what the actions should be
Phillip J. Eby wrote:
How much any of that could have also applied to the distutils at one
time, I don't know. My point is merely that setuptools has enough
commercial value to make me believe that sponsorship for features
shouldn't be that hard to come by, and there are certainly worse
Anthony Baxter wrote:
4. .egg files. -1
As far as I understand it, an egg file is just a zipimport format zip
file with some additional metadata. You can also install the egg
files in an unpacked way, if you prefer that. I don't understand the
objection here - it's no better or worse
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
Certainly. However, I get two conclusions out of this:
1. don't load
Jérôme Laheurte wrote:
Sorry I'm late, but something like os.popen('taskkill.exe /F /IM
python_d.exe') would have worked; we use this at work.
Thanks, I didn't know about it. Is it available on Windows 2000,
too? (because the system in question is Windows 2000, and I see
it on a What's new in
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
will simply be a delivery mechanism for eggs.
That might
Ronald Oussoren wrote:
As far as I understand the issues they compete up to a point, but should
also make it easier to create platform packages that contain proper the
proper dependencies because those are part of machine-readable meta-data
instead of being written down in readme files. Oddly
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource fork
contained pieces of data called resources.
I can
Bob Ippolito wrote:
'There are several binary formats that embody eggs, but the most common
is '.egg' zipfile format, because it's a convenient one for distributing
projects.'
'.egg files are a zero installation format for a Python package;'
single modules are also such a zero installation
Ian Bicking wrote:
I don't think setuptools version requirements are enough to ensure the
integrity of all pieces of a complex system will work together.
Figuring out a self-consistent set of packages to work together is
something that is rather independent of any particular package, and
Dennis Heuer wrote:
Module names
like hashlib are not python-like too (too c/lowlevel-like).
I agree with Greg: hashlib is a Pythonic name for a module,
just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
difflib, ...
OTOH, it might be indeed that the ctypes name need to be
aligned
Ronald Oussoren wrote:
That doesn't require Eggs to be single-file zipfiles; deleting a
directory would work just as will (and I believe it will work with
ez_install, too).
Egg directories (which are basically just the same as packages using
.pth files) also work for this and that's what I
Jérôme Laheurte wrote:
Ah, no, it's only available in XP. There are some alternatives though:
http://www.robvanderwoude.com/index.html
Sure. Writing my own one wasn't that difficult, in the end, either
(except that I overlooked that the API I used first exists in XP
and later only).
regards,
Greg Ewing wrote:
Guido van Rossum wrote:
You
can't blame KDE for providing mechanisms that only work in the KDE
world. It's fine for Python to provide Python-specific solutions for
issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources
Thomas Heller wrote:
Personally, I *like* the ctypes name. But I'm open for suggestions,
and it might have intersting consequences if the Python core package
would be renamed to something else.
Any suggestions?
Well, my only concern was py_object. I wondered whether the py_
prefix is
Guido van Rossum wrote:
Microsoft just announced that Visual Studio 2005 express will be free
forever, including the IDE and the optimizing C++ compiler. (Not
included in the forever clause are VS 2007 or later versions.)
Does this make a difference for Python development for Windows?
For
Thomas Heller wrote:
On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
after adding bufferoverflowU.lib to the linker options.
On what project? There should be /GS- options on all projects that need
it, which, in turn, should result in bufferoverflowU.lib not being
Giovanni Bajo wrote:
It's been possible to compile distutils extensions with the VS 2003 toolkit
for far longer than it's possible to compile Python itself:
http://www.vrplumber.com/programming/mstoolkit/
Sure: with distutils modifications.
In fact, it would be great if the patches provided
Thomas Heller wrote:
I forgot to mention that there are a lot of warnings about conversion
betweem Py_ssize_t to int - if you want me to fix the obvious ones
I'll offer to correct some of them from time to time and commit the
changes.
Right - they have been there ever since I started (in
Neal Norwitz wrote:
Right - they have been there ever since I started (in fact, I started
this entire project *because* of these warnings). You can get them on
x86, too, if you enable /Wp64.
In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C
compiler).
It still isn't
Guido van Rossum wrote:
Leaving aside the Perl vs. Py thing, opinions on CPAN seem to be
diverse -- yes, I've heard people say that this is something that
Python sorely lacks; but I've also heard from more than one person
that CPAN sucks from a quality perspective. So I think we shouldn't
Kirat Singh wrote:
Hi, this is my first python dev post, so please forgive me if this topic
has already been discussed.
To my knowledge, this hasn't been discussed before.
It seemed to me that removing me_hash from a dict entry would save 2/3
of the space used by dictionaries and also
Anthony Baxter wrote:
On Saturday 22 April 2006 15:27, Neal Norwitz wrote:
In case it wasn't clear, the /Wp64 flag is available in icc
(Intel's C compiler).
Is it worth turning this on for the icc ubuntu buildbot? Anyone got
ideas on the best way to do this? Should I just set CFLAGS=-Wp64
Tim Peters wrote:
I've never reported this as a Python bug
If you do, I'll probably add a comment like the above ;-)
because I've considered the antivirus SW likely to be the culprit.
Could be. FWIW, Norton AV was running during the above.
I see a similar phenomenon (sp?) on XP SP2:
Kirat Singh wrote:
The reason I looked into this to begin with was that my code used up a
bunch of memory which was traceable to lots of little objects with
instance dicts, so it seemed that if instancedicts took less memory I
wouldn't have to go and add __slots__ to a bunch of my classes, or
Sean Reifschneider wrote:
Thoughts?
In Python 2.5, exit(0) exits.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Martin v. Löwis wrote:
- Paul Moore has contributed a Python build procedure for the
free version of the 2003 compiler. This one is without IDE,
but still, it should allow people without a VS 2003 license
to work on Python itself; it should also be possible to develop
extensions
Guido van Rossum wrote:
Actually, what Nick describes is *exactly* how one should write code
using a condition variable:
LOCK
while nothing to do:
UNLOCK
wait for the condition variable (or sleep, or whatever)
LOCK
# here we have something to do with the lock held
Neil Hodgson wrote:
I expect Microsoft means that Visual Studio Express will be
available free forever, not that you will always be able to download
Visual Studio 2005 Express. They normally only provide a particular
product version for a limited time after it has been superceded.
Sure:
Alex Martelli wrote:
For the Toolkit 2003:
http://tinyurl.com/gv8wr
When I go to this URL, I get redirected to
http://www.microsoft.com/downloads/details.aspx?familyid=272BE09D-40BB-4displaylang=en
This doesn't look right - it ought to be a UUID. Anyway, I get a page
that reads
The download
John J Lee wrote:
Actually, it's apparently still there, just at a different URL.
Somebody posted the new URL on c.l.py a day or two back (Alex Martelli
started the thread, IIRC). I'm off to the dentist, no time to Google
for it!
Please do. If you find the URL, please post it here. All URLs
Sylvain Thénault wrote:
I've posted a patch (#1475523) for this and assigned it to Martin Von
Loewis since he was the core developper who has made some followup on
the original bug. Could someone (Martin or someone else) quick review
this patch ? I really need a fix for this, so if anyone
Tim Peters wrote:
Does
with cv:
work to replace the outer (== only) acquire/try/finally/release dance?
Indeed it does - although implemented in a somewhat convoluted way:
A lock *is* a context (or is that context manager), i.e. it implements
def __context__(self): return self
Guido van Rossum wrote:
Tim is right, the UNLOCK/LOCK part is implied in the wait() call.
However, the wait() implementation really *does* provide a use case
for the primitive operation that Nick proposed, and it can't be
refactored to remove the pattern Martin disapproves of (though of
Brett Cannon wrote:
I created patch 1474907 with a fix for it. Checks if %zd works for
size_t and if so sets PY_FORMAT_SIZE_T to z, otherwise just doesn't
set the macro def.
Assigned to Martin to make sure I didn't foul it up, but pretty much
anyone could probably double-check it.
[EMAIL PROTECTED] wrote:
[...]
Should be closed/rejected. [...]
Neal S 304 Controlling Generation of Bytecode Files Montanaro
Probably ditto.
Rejected would be a wrong description, IMO; withdrawn describes it
better. It's not that the feature is undesirable or the specific
Michael Hearne wrote:
If I want to keep these classes as distinct modules, but retain this
kind of module interdependency, how can I architect this with Python?
Please understand that python-dev is for discussions about the
development *of* Python, not for the development *with* Python.
Use
Phillip J. Eby wrote:
My counter-proposal: to be considered a package, a directory must contain
at least one module (which of course can be __init__). This allows the is
it a package? question to be answered with only one directory read, as is
the case now. Think of it also as a nudge in
Phillip J. Eby wrote:
At 11:50 AM 4/26/2006 -0700, Guido van Rossum wrote:
I'm not sure what you mean by one directory read. You'd have to list
the entire directory, which may require reading more than one block if
the directory is large.
You have to do this to find an __init__.py too,
Phillip J. Eby wrote:
I assume you want
import x.y
to fail if y is an empty directory (or non-empty, but without .py
files). I don't see a value in implementing such a restriction.
No, I'm saying that tools which are looking for packages and asking, Is
this directory a package? should
Dennis Heuer wrote:
The reason why I'd like to use the long type as the base of my bitarray
type is that the long type is already implemented as an array and
working efficiently with large amounts of bytes.
This is wrong; you are mixing up the is-a and has-a relationships.
While it might be
Simon Dahlbacka wrote:
OTOH, the ETA for Vista is just after 2.5 release (end of 2006 for
OEM:s, beginning of 2007 for customers), long before 2.6
That said, I don't have any strong preferences either way. (..but I do
have a x64 Vista machine running ATM)
Good to know, but unfortunately,
Dennis Heuer wrote:
The real misunderstanding lies somewhere else. I thought that the
bitarray's instance would have more control over the long type's
instance, like with the mutable types. I thought that the long type's
superclass would provide methods similar to __setitem__ that would
allow
Dennis Heuer wrote:
I hope that somebody agrees and is already starting to implement this
new array type. My best wishes are with you.
This is off-topic for python-dev. Please post to comp.lang.python instead.
Regards,
Martin
___
Python-Dev mailing
Simon Dahlbacka wrote:
Given that, it does not really seem feasible to include them..
Ok, thanks for the investigation.
Speaking of icons, do the bundled ico files have to be named py.ico and
pyc.ico?
No. I think I'll try to drop them altogether, getting the icons from
python_icon.exe only.
Thomas Wouters wrote:
Indeed! I hadn't realized that, although I might've if I'd been able to
find where Modules is put on sys.path. And, likewise, I would do as you
suggest (which feels like the right thing) if I could only find out
where Modules is put on sys.path :) I don't have time to
Ronald Oussoren wrote:
That's fine by me. I'll be adding them to the universal python 2.4
tree soon and to 2.5 when that's is done. Do have to wait for the
contributor agreement, which the folks over at [EMAIL PROTECTED] say is
good enough, to do that?
If the artist has informally
Georg Brandl wrote:
As I posted here previously, I contacted the owner, and he said that he
didn't care about specifying a license. I guess that means that we can
pick one ;)
Can you please ask whether he would be willing to fill out a contrib
form
Vladimir 'Yu' Stepanov wrote:
* To adapt allocation of blocks of memory with other alignment. Now
alignment is rigidly set on 8 bytes. As a variant, it is possible to
use alignment on 4 bytes. And this value can be set at start of the
interpreter through arguments/variable environments/etc.
Terry Reedy wrote:
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s) without the
parameter name?
Are you asking why that feature (keyword-only arguments) is desirable?
That's the whole point of the PEP. Or are
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing something?
I think what you are missing is that algorithms
Josiah Carlson wrote:
I think what you are missing is that algorithms that currently operate
on byte strings should be reformulated to operate on character strings,
not reformulated to operate on bytes objects.
By character strings can I assume you mean unicode strings which
contain data,
Aahz wrote:
First of all, I recommend that you post this to comp.lang.python. This
is the kind of PEP where wide community involvement is essential to
success; be prepared for massive revision.
Actually, *all* PEPs should be posted to c.l.p at some point; the PEP
author is responsible for
Jeff Epler wrote:
However, on this system, I couldn't recreate the problem you reported
with either the using _tkinter directly instructions, or using this
C test program:
#include tcl.h
#include tk.h
int main(void) {
Tcl_Interp *trp;
unsetenv(DISPLAY);
trp =
Josiah Carlson wrote:
I mean unicode strings, period. I can't imagine what unicode strings
which do not contain data could be.
Binary data as opposed to text. Input to a array.fromstring(),
struct.unpack(), etc.
You can't/shouldn't put such data into character strings: you need
an encoding
Terry Reedy wrote:
Are you asking why that feature (keyword-only arguments) is desirable?
That's the whole point of the PEP. Or are you asking why the user
shouldn't be allowed to pass keyword-only arguments by omitting the
keyword? Because they wouldn't be keyword-only arguments then,
Terry Reedy wrote:
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s) without the
parameter name?
Like Martin, you clipped most of the essential context of my question:
Talin's second proposal.
I clipped it
Thomas Wouters wrote:
It seems that, on my platform at least, Tk_Init() doesn't like being
called twice even when the first call resulted in an error. That's Tcl
and Tk 8.4.12. Tkapp_Init() (which is the Tkinter part that calls
Tk_Init()) does its best to guard against calling Tk_Init() twice
Edward Loper wrote:
Martin v. Löwis wrote:
One reason I see is to have keyword-only functions, i.e. with no
positional arguments at all:
def make_person(*, name, age, phone, location):
pass
But is it necessary to syntactically *enforce* that the arguments be
used as keywords
Terry Reedy wrote:
This is not a reason for subproposal two, but a special case, as you
yourself note below, and hence does say why you want to have such.
def make_person(*, name, age, phone, location):
pass
You weren't asking for a reason, you were asking for an example:
this is one.
Guido van Rossum wrote:
Agreed. Is it too late to also attempt to bring Doc/ref/*.tex
completely up to date and remove confusing language from it? Ideally
that's the authoritative Language Reference -- admittedly it's been
horribly out of date but needn't stay so forever.
It's never too late
Guido van Rossum wrote:
Strange. I thought this was supposed to be fixed? (But I can confirm
that it isn't.)
Perhaps you were confusing it with this HISTORY entry?
- A 'continue' statement can now appear in a try block within the body
of a loop. It is still not possible to use continue in a
Fredrik Lundh wrote:
the language reference says:
continue may only occur syntactically nested in a for or while loop,
but not nested in a function or class definition or finally statement
within that loop. /.../
It may occur within an except or else clause. The
Josiah Carlson wrote:
Certainly that is the case. But how would you propose embedded bytes
data be represented? (I talk more extensively about this particular
issue later).
Can't answer: I don't know what embedded bytes data are.
Ok. I think I would use base64, of possibly compressed
Fredrik Lundh wrote:
for some reason, the language reference uses the term string con-
version for the backtick form of repr:
http://docs.python.org/ref/string-conversions.html
any suggestions for a better term ? should backticks be deprecated,
and documented in terms of repr (rather
Luke Dunstan wrote:
1. Is there any reason in principle why patches for Windows CE support would
be rejected?
No, not in principle. Of course,
- the patch shouldn't break anything
- you should state an explicit commitment to support the port for
some years (or else it might get removed at
Fredrik Lundh wrote:
I'm +1 on adding --help and --version, +1 on adding -? and /? for windows
only,
-0=slightly sceptical if adding a generic long option machinery is worth it,
and -1
on a guessing machinery.
I also agree with all these judgments.
Regards,
Martin
Paul Moore wrote:
Is it possible to create a branch in the main Python svn, and grant
commit privs to that branch only, for sprint participants? I seem to
recall something like mod_authzsvn being involved, but I don't know
much more...
We couldn't technically enforce it - but I'm sure sprint
Benji York wrote:
I'm not familiar with the mechanics, recent versions of Subversion allow
per-directory security. We do this to give some customers read access
to parts of the repo, and read-write to others. It shouldn't be
difficult (given a recent enough Subversion) to set up a sprint
Vladimir 'Yu' Stepanov wrote:
Yes. I understood it when resulted a set example.
However, as I just said, people usually don't remove items from
just-sorted lists, they tend to iterate over them via 'for i in list:' .
Such problem arises at creation of the list of timers.
For a list of
Greg Ewing wrote:
Tim Peters wrote:
Instead it would make best sense for each
sprint project to work in its own branch, something SVN makes very
easy, but only for those who _can_ commit.
There's no way of restricting commit privileges to
a particular branch?
In the current setup, not
801 - 900 of 4853 matches
Mail list logo
