Guido van Rossum wrote:
Why? You can flush it and then all the data is on the disk.
That might be all right on Unix, but I would be
worried that having the file open could prevent
some other things being done with it on some
platforms, such as renaming. You might also want
to pass the file nam
Facundo Batista wrote:
Has super() proved more useful than harmful? Which is the value for
Py3 to keep it?
Personally I've found exactly zero use cases for super()
so far in my own code. A couple of times I thought I'd
found one, but it turned out not to do quite what I
wanted, and I ended up
Guido van Rossum wrote:
The
alternative would be to make it a keyword, which seemed excessive
(plus, it would be odd if super() were a keyword when self is not).
If it's really such a useful thing as to warrant so much
magic to support it, then I think it deserves to have a
keyword.
Conversely
Phillip J. Eby wrote:
(Note, by the way, that you cannot safely write an upcall in a mixin
class without super, so it can't safely be done away with, anyway.)
It seems to me you can't safely write one in a mixin class
*with* super either. I know that's what it's supposed to be
for, but I can't
Gustavo Carneiro wrote:
A better question would be, is multiple inheritance good or bad for
programs? :-)
I would say there are good ways of using it, and bad
ways of using it.
In my experience, the good ways occur when the classes
being mixed together are completely independent -- there
is n
Jared Flatow wrote:
I agree that if your methods are 'clashing' then you are
probably misinheriting, but cooperative methods can be the most natural
way to model certain situations.
I'm not saying that nobody should ever use super, only
that it's not the right thing for the situation I was
Raymond Hettinger wrote:
lastname_firstname = lambda r: (r[0].lower(), r[5].lower())
for k, g in groupby(iterable, key=lastname_firstname): ...
That transformation adds clarity. Going further and creating a separate
def-statement outside the current function would just move the relevant
co
Armin Rigo wrote:
More precisely, the sprint will be in the crashed c-base space station,
Berlin, Germany, Earth, Solar System.
You have a crashed space station in Berlin? Wow! I hope
it didn't come down on anything important...
--
Greg
___
Python-De
Boris Borcic wrote:
def inst.bar(...) : ...
def fn[k](...) : ...
should be similarly permitted. Has this ever been discussed ?
Yes, but there didn't seem to be much interest in
the idea. Which is disappointing, because it would
be ideal for setting up function tables and such
like.
O
Terry Reedy wrote:
In any case, American programmers are not 'average' Americans ;-).
So I say use it!
Plus, think of all the millions of people who will have
their lives enriched by learning to spell 'Rietveld'
properly!
--
Greg
___
Python-Dev mail
Jeroen Ruigrok van der Werven wrote:
Is it a reference to Gerrit Rietveld (Dutch architect and furniture
designer)? I guess the architect part would make sense for a code review
tool. :)
According to Wikipedia, he was also a friend of Mondrian
and incorporated some of Mondrian's ideas into his
Tristan Seligmann wrote:
The correct way to do this is to create a temporary directory, and then
generate a filename underneath that directory to use.
Yes, otherwise you can get bitten by the race condition
that's the reason for mktemp being deprecated.
--
Greg
___
[EMAIL PROTECTED] wrote:
> I guess we're going to have to agree to disagree. I find hiding directories
> which contain executable code extremely non-obvious.
I'm worried by this too. I don't like the idea of putting
large and important things in hidden directories automatically
without being tol
Steve Holden wrote:
If you want it visible, make a visible symbolic link!
I have to know it's there first. The idea of an installer
deliberately hiding stuff from me in a very unconventional
and non-obvious way makes me uncomfortable.
--
Greg
___
Py
Guido van Rossum wrote:
The location will be somewhere under ~/.local
for Unix/Linux/OS X,
Can I just put in a plea for this to be somewhere
under ~/Library on OSX, and not hidden?
MacOSX already has clear conventions for this sort
of thing -- there's no need to use a dot-name there.
--
Greg
Antoine Pitrou wrote:
When you write a processing
script for internal use there's no reason to worry about security issues like
that
Even without security issues, there's still the potential
for two processes creating temp files at the same time to
trip over each other.
--
Greg
___
Bill Janssen wrote:
The HTTP client-side library calls "makefile" on the socket, then
closes it, then passes the file returned from "makefile" on to
application code to work with.
Seems to me we really need two different APIs for
doing a makefile()-like operation, depending on
whether you're e
Christian Heimes wrote:
Can you come up with a path that fits the purpose of a base directory?
"~/Library/Application Support/Python" would seem to be
appropriate.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
Christian Heimes wrote:
Can you come up with a path that fits the purpose of a base directory?
Second thoughts, I think there's something better -- there's
already a system-supplied directory on my system called
/Library/Python/2.3 with a site-packages containing a
README that says it's for in
[EMAIL PROTECTED] wrote:
While Python doesn't have a char type (yet), I still find the distinction
between 'c' and "abc" useful to show intent (especially given my C
background
The way I tend to use them is that "xxx" is for data
operated on by the program and seen by the user,
and 'xxx' is fo
Steven D'Aprano wrote:
The only thing I can think of is printing lines with line numbers
Parsing a file and wanting to be able to print
error messages with line numbers would seem to
be a fairly likely use.
--
Greg
___
Python-Dev mailing list
Python-
Steven D'Aprano wrote:
With iterators being such a fundamental part of Python these days,
perhaps one day we'll see the functions in the itertools module become
iterator methods
I hope not. The set of potential functions that operate
on iterators is open-ended, and there's no reason to
single
Jesse Noller wrote:
I am looking for any questions, concerns or benchmarks python-dev has
regarding the possible inclusion of the pyprocessing module to the
standard library
Sounds good, but I'd suggest giving a more specific
name than "processing", which is so generic as to
be meaningless.
--
Nick Coghlan wrote:
Talin wrote:
multiprocessing
multiprocessing would work for me
Me, too.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
M.-A. Lemburg wrote:
The API of the processing module does look simple and nice, but
parallel processing is a minefield - esp. when it comes to handling
error situations (e.g. a worker failing, network going down, fail-over,
etc.).
What I'm missing with the processing module is a way to spawn p
Andrew McNabb wrote:
If it made people feel better, maybe it should be called threading2
instead of multiprocessing.
I think that errs in the other direction, making it sound
like just another way of doing single-process threading,
which it's not.
Maybe "multicore" would help give the right i
Charles Cazabon wrote:
"threading" is to threads as "processing" is to processes; that's why it was
named processing.
Unfortunately, the word "processing" is already used in the
field of computing with a very general meaning -- any kind
of data transfomation at all can be, and is, referred to a
Tom Pinckney wrote:
If I look at top while
running 2 or more threads, both cores are being used 100% and there is
no idle time on the system.
If you run it with just one thread, does it use up only
one core's worth of CPU?
If so, this suggests that the GIL is being released. If
it wasn't, two
Alexandre Vassalotti wrote:
On Sat, May 17, 2008 at 5:05 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
Object serialization protocols like e.g. pickle usually store the
complete module path to the object class together with the object.
The opposite problem exists for Python 3.0, too.
This is
Nick Coghlan wrote:
So what do people think of including a ProxyBase implementation in 2.6
and 3.0 that explicitly delegates all of the C-level slots to a
designated target instance?
Sounds good to me.
--
Greg
___
Python-Dev mailing list
Python-Dev@
Christian Heimes wrote:
I assume recvfd and sendfd
aren't syscalls but the proposed names for the functions.
Yes, the functionality in question is accessed through
the sendmsg() and recvmsg() system calls.
--
Greg
___
Python-Dev mailing list
Python-D
Christian Heimes wrote:
Thankfully this issue was fixed in Python 2.6 and 3.0. In newer versions
of Python hasattr() only swallows exception based on the Exception class
but not BaseExceptions.
Shouldn't it only be catching AttributeError, though?
We should make sure all code in the core beha
I wrote:
Shouldn't it only be catching AttributeError, though?
Forget that, I forgot that PyObject_HasAttr can't
signal an exception.
The Py3 C API should be designed to fix this, I think.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Martin v. Löwis wrote:
IIRC, it chokes on the attempt to compile assembler code that
has C preprocessor macros in it (can't test it right now).
Could the build process be modified to run the C preprocessor
over the assembly language first?
--
Greg
__
Facundo Batista wrote:
A thread in PyAr raised the question that, considering that strings
are immutable, why a slice of a string is a copy and not a reference
to a part of that string.
Because it would make it too easy to accidentally keep
a large string alive via a reference to a small part
Armin Ronacher wrote:
I'm currently not
providing any __r*__ methods as I was too lazy to test on each call if the
method that is proxied is providing an __rsomething__ or not, and if not come up
with an ad-hoc implementation by calling __something__ and reversing the
arguments passed.
I don't
Nick Coghlan wrote:
else:
# Returned a different object, make a new proxy
result = type(self)(result)
You might want to check that the result has the
same type as the proxied object before doing that.
--
Greg
___
Python-Dev maili
Paul Moore wrote:
I'd rather see a solution which addressed the
wider visitor use case (I think I just sprained my back bending over
backwards to avoid mentioning generic functions :-))
Speaking of generic functions, while thinking about the
recent discussion on proxy objects, it occurred to me
Bill Janssen wrote:
Look, even if there were *no* additional methods, it's worth adding
the base class, just to differentiate the class from the Sequence, as
a marker, so that those of us who want to ask "isinstance(o, String)"
can do so.
Doesn't isinstance(x, basestring) already cover that?
Mike Klaas wrote:
In my perfect world, strings would be indicable and sliceable, but not
iterable.
An object that was indexable but not iterable would
be a very strange thing. If it has __len__ and __getitem__,
there's nothing to stop you iterating over it by hand
anyway, so disallowing __ite
Mike Klaas wrote:
I agree that it would be perverse to disallowing iterating over a
string.
Just to be clear, I'm saying that it would be perverse
to disallow iterating *but* to allow indexing of
individual characters. Either you should have both or you
should have neither.
--
Greg
Georg Brandl wrote:
Greg Ewing schrieb:
>
Doesn't isinstance(x, basestring) already cover that?
That doesn't cover UserString, for example.
A better solution to that might be to have UserString
inherit from basestring.
--
Greg
_
Nick Coghlan wrote:
I don't think it would actually be that much worse - something like
typetools.ProxyMixin would just involve a whole series of register calls
instead of method definitions. I wouldn't expect the total amount of
code involved to change much.
I'm not thinking about the __xxx_
Nick Coghlan wrote:
That's where the generic system itself needs to
be based on generic functions - then you can hook the lookup function so
that proxies get looked up based on their target type rather than the
fact they're a proxy. It all gets very brain bending and self
referential, which is
Georg Brandl wrote:
Greg Ewing schrieb:
A better solution to that might be to have UserString
inherit from basestring.
But with that argument you could throw out the whole ABC machinery,
just let all lists inherit from list, all dicts from dict, etc.
Well, I'm skeptical about the whol
Armin Ronacher wrote:
basestring is not subclassable for example. Also it requires subclassing
which ABCs do not.
The use case that was cited was recognising subclasses of
UserString, and that's what I was responding to. If
basestring were made subclassable and UserString inherited
from it, t
Guido van Rossum wrote:
There are quite a few core APIs that accept no
substitutes, and being an instance of basestring was intended to
guarantee that a value is accepted by such APIs.
In that case, the idea of a user-defined string class
that doesn't inherit from str or unicode seems to be
a l
Benjamin Peterson wrote:
I agree that the threading the the pyprocessing APIs should be PEP 8
compliant, but I think 2 APIs is almost worse than one wrong one.
So change them both to be PEP 8 compliant, and leave
aliases in both for existing code to use.
--
Greg
___
Nick Coghlan wrote:
- remove support for passing a single value to a format string without
wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
--
Greg
___
Python-Dev
Paul Moore wrote:
Because the second breaks if value is a tuple:
However, changing it now is going to break a huge
amount of existing code that uses %-formatting,
and in ways that 2to3 can't reliably fix.
Keeping %-formatting but breaking a large
proportion of its uses doesn't seem like a goo
Nick Coghlan wrote:
%r is about the worst case for the new syntax relative to the old - two
characters become 5. It's worth looking at what those extra characters
buy us though:
However, those benefits are only realised some of the
time, and it's only in rare cases that they're all
realised at
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
"{num} occurs {num} times in this format string".format(dict(num=2))
If named arguments were to become mandatory, I'd want
to be able to write tha
Maciej Fijalkowski wrote:
What do you think about this code:
class A:
locals()[42] = 98
Seems people rely on it working. Do we consider it part of python
language?
Modifying the dict returned by locals() is documented
as NOT being guaranteed to work, isn't it?
--
Greg
Cesare Di Mauro wrote:
However, I don't agree with the FAQ on this point. I think that a
> Pascal-like with statement can be achieved, even with a dynamic
> language such as Python, and in a simple way.
It's not so much a matter of whether it *can* be done, but
whether there's any substantial
Cesare Di Mauro wrote:
The same happens with:
from Tkinter import *
which is a fair common instruction...
...and which should *not* be used in most cases, for
the same reason.
All those tutorials that start out with 'from something
import *' are doing a lot of harm to the impressionable
min
Talin wrote:
In some cases, the term is used to mean a
dictionary that remembers the order of insertions, and in other cases it
is used to mean a sorted dict,
I would be more in favor of the idea if we could come up with a less
ambiguous naming scheme.
Perhaps "indexed list" or maybe "keyed
Cesare Di Mauro wrote:
OK, but nobody have questioned about removing 'from something import *' just to
help noobs...
I'm not advocating removing it from the language, far
from it. I agree there are legitimate uses for it in
rare cases.
I just wish that people wouldn't use it in tutorials,
wh
Alexandre Vassalotti wrote:
Do you have any idea how this behavior could be fixed? I am not a GC
expert, but I could try to fix this.
Perhaps after making a GC pass you could look at the
number of objects reclaimed during that pass, and if
it's less than some fraction of the objects in existen
Martin v. Löwis wrote:
Under my proposal, 10 middle collections must have passed,
PLUS the number of survivor objects from the middle generation
must exceed 10% of the number of objects in the oldest
generation.
What happens if the program enters a phase where it's not
producing any new cyclic
Martin v. Löwis wrote:
Wouldn't it be simpler just to base the collection frequency
directly on the total number of objects in the heap?
Using what precise formula?
The simplest thing to try would be
middle_collections >= num_objects_in_heap * some_constant
--
Greg
___
Jeff Hall wrote:
I mistakenly thought that was
because they were assumed to be small. It sounds like they're ignored
because they're automatically collected and so they SHOULD be ignored
for object garbage collection.
Strings aren't tracked by the cyclic garbage collector
because they don't c
Raymond Hettinger wrote:
To me, the one obvious way to convert a number to a
eval-able string in a different base is to use bin(), oct(), or hex().
What use cases are there for an eval-able representation
of a float in those bases, as opposed to a human-readable
one?
--
Greg
tomer filiba wrote:
>>> def f(**kwargs):
... print kwargs
...
>>> f(a=5,b=7,a=8)
{'a': 8, 'b': 7}
>>>
I can't think of any reason why one would need to be
able to write such code, or even want to.
--
Greg
___
Python-Dev mailing list
Python-De
Chris AtLee wrote:
One thing I've always missed in urllib/urllib2 is the
facility to encode POST data as multipart/form-data.
I second that, having had to reinvent it a couple of
times recently. It seems like an obvious thing to want
to do, and it's surprising to find it's not supported.
--
Gr
Nick Coghlan wrote:
It's a fact of Python development: __del__ methods cannot safely
reference module globals, because those globals may be gone by the time
that method is invoked.
Speaking of this, has there been any more thought given
to the idea of dropping the module clearing and just
rel
Since it's already possible for __del__-containing cycles
to survive interpreter shutdown, I don't see that this
issue ought to be a showstopper for elimination of module
clearing.
Also, it seems to me that the kind of cycles module
clearing is designed to break, i.e. those between classes,
funct
Ben Finney wrote:
That's another reason to avoid "assert" in the name: these methods
*don't* necessarily use the 'assert' statement. Avoiding the
implication that they do use that is a good thing.
Perhaps some positive alternative such as "verify" could
be used instead.
--
Greg
__
Steve Holden wrote:
"Fail" isn't a negative.
That depends on what you're trying to find out by reading
the code. If you're trying to find out under what conditions
the test succeeds, then it succeeds if it doesn't fail, so
you have a negative.
Whichever convention is chosen, there will be sit
Jonathan Lange wrote:
My name's Jonathan, and I spell "set up" as "set up" and "tear down"
as "tear down".
In English, it depends on how they're being used. As
nouns they're single words, as verbs they're two
words.
As function names, they could be read either way, so
it comes down to readabi
Richard Thomas wrote:
I've been told by a couple of non-programmers that "failUnless" is
more intuitive than "assert" if only for the reason that its unclear
what "assert" might do.
But test frameworks are for use by programmers, not
non-programmers. Given that it's a test framework, would
a p
Ben Finney wrote:
Nick Coghlan <[EMAIL PROTECTED]> writes:
> the shortest
> possible way of writing negative assertions (i.e. asserting that
> something is not the case) is to treat them as denials and use the
> single word 'deny'.
This, to me, is neither intuitive nor meaningful in context. Th
Josiah Carlson wrote:
It's entirely possible that I know very little about what was being
made available via the bsddb module, but to match the API of what is
included in the documentation (plus the dictionary interface that it
supports) shouldn't be terribly difficult.
Maybe for new databases,
Sebastien Loisel wrote:
Essentially, in almost all applications, inv(A) is entirely wrong. You
can ask any numerical analyst who works with large problems, and they
will confirm it. One of the main reason is that, even if A is sparse,
inv(A) is full.
This argues for a function such as solve(
Josiah Carlson wrote:
What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's
a custom infix operator. But where is it defined?
It's not quite as bad as that -- it would be defined by
the relevant operator method on one of the operands. But
a convention would be needed for mappi
Terry Reedy wrote:
Given that itertools.product(A,B) == ((x,y) for x in A for y in B)
== the proposed 'A @ B' and given Guido's pronounced distaste for new
infix, should this be closed?
Would there likely be any support for an alternative
PEP defining @ as matrix multiplication in both Python
Thomas Lee wrote:
I'm making some good progress with the AST optimizer, and now the main
thing standing in my way is lnotab.
My suggestion would be to drop the idea of trying to
compress the lnotab in clever ways, and just make it
a straightforward list of bytecode offset/line number
pairs. I c
Scott Dial wrote:
Perhaps I'm nobody, but I think this would be ridiculous. Matrices are
not native objects to the language.
Why should that matter? We already have things like
sum(), which operates on any sequence of numbers,
without needing a special "array of numbers" data
type. I don't see
Fredrik Johansson wrote:
Anyway, it is easy to define pseudo-operators in Python;
A *matrixmul* B
A *dot* B
A *cross* B
A *elementwise* B
Urg. This is another one of those recipes that I consider
is too clever for its own good. Very nice in theory,
but I would never use it in real life.
What
Scott Dial wrote:
I would argue that Python contains a "array of some_type" data type.
That sum() performs a left-fold of __add__ on the array is completely
independent of them being numbers.
That's not strictly true -- it explicitly refuses to operate
on strings (or at least it did last time
Josiah Carlson wrote:
This is the first time anyone has mentioned "conciseness" in this
thread.
I thought it more or less went without saying. After
all, if conciseness isn't a goal, there's nothing
wrong with a plain function call, which can be as short
as 3 characters as well.
The trouble i
Sebastien Loisel wrote:
What are the odds of this thing going in?
I don't know. Guido has said nothing about it so far this
time round, and his is the only opinion that matters in the
end.
I may write a PEP about this. However, since yesterday I've
realised that there's a rather serious probl
[EMAIL PROTECTED] wrote:
How about just making a matrix multiply function that can take many
arguments? I think this is pretty readable:
mmul(a, b, c, d)
The multiplications aren't necessarily all together, e.g.
a*b + c*d + e*f
would become
mmul(a, b) + mmul(c, d) + mmul(e, f)
--
Gre
Guido van Rossum wrote:
last time '@' was considered as a new operator, that character had no
uses in the language at all. Now it is the decorator marker.
The only alternatives left would seem to be ?, ! or $,
none of which look particularly multiplicationish.
But would it be totally outland
Sebastien Loisel wrote:
let
me describe MATLAB's approach to this. It features a complete suite of
matrix operators (+-*/\^), and their pointwise variants (.+ .- ./ .*
.^)
That was considered before as well, but rejected on
the grounds that the dot-prefixed operators were too
cumbersome to use
Fredrik Johansson wrote:
Further, while A**B is not so common, A**n is quite common (for
integral n, in the sense of repeated matrix multiplication). So a
matrix multiplication operator really should come with a power
operator cousin.
Which obviously should be @@ :-)
Well, Fortress probably
Martin v. Löwis wrote:
(maybe the use of the question mark is more typical in German
than in English; my stomach turns around when I read a question
that ends with a full stop)
No, it's required in English, too.
--
Greg
___
Python-Dev mailing lis
Kless wrote:
So the next encoding possible would of base-128 (7-bits encoding)
A while ago I wanted to pack as much information as
possible into a string of printable characters, and
I came up with a base-95 encoding that packs 9 bytes
into 11 characters.
The application involved representing
Guido van Rossum wrote:
Hm, I'm sure there were many more, perhaps in different places.
Although it wasn't April 1, here's one I posted
in response to python-dev discussions.
http://mail.python.org/pipermail/python-list/2001-May/084169.html
There was also another one concerning how to reduce
Paul Pogonyshev wrote:
del obj.x
obj.x = y
though I'm not sure if for Python code x.__del__ will see obj.x as
non-set attribute (I guess so, but I'm not sure).
A quick experiment suggests that it does:
Python 2.5 (r25:51908, Apr 8 2007, 22:22:18)
[GCC 3.3 20030304 (Apple Com
Guido van Rossum wrote:
If you call:
subprocess.call(cmd, shell=False)
Then it works on Linux, but fails on Windows because it does not
perform the Windows %PATHEXT% search that allows it to find that
"svn.exe" is the actual executable to be invoked.
Maybe the Windows implementation shou
Phillip J. Eby wrote:
ISTR pointing out on more than one occasion that a major use case for
co-operative super() is in the implementation of metaclasses. The
__init__ and __new__ signatures are fixed, multiple inheritance is
possible, and co-operativeness is a must
Do you have a real-life e
M.-A. Lemburg wrote:
The typical use is in mixin classes that can be used to
add functionality to base classes...
But this is just another waffly made-up example. I'm
talking about real-life use cases from actual code
that's in use.
--
Greg
___
Pyth
Steven D'Aprano wrote:
I don't think M.__file__ should lie and say it was loaded from a file
that it wasn't loaded from. It's useful to be able to look at a module
and see what file it was actually loaded from.
On the other hand, it could be useful to be able to find
the source file for a mod
Antoine Pitrou wrote:
I don't see a problem for trivial functional wrappers to classes to be
capitalized like classes.
The problem is that the capitalization makes you
think it's a class, suggesting you can do things
with it that you actually can't, e.g. subclassing.
I can't think of any reas
Tony Nelson wrote:
I suppose the question is what a capitalized name promises. If it means
only "Class", then how should "Returns a new object", either from a Class
or a Factory, be shown?
Is there really a strong need to show that? There are
many ways in which functions could be categorized.
Steven D'Aprano wrote:
Why not expose the class directly, instead of
making it private and then exposing it via a factory function that does
nothing else?
This option would also have the advantage of not
changing the API (unless there's code out there that
actually depends on them *not* being
Jesus Cea wrote:
How do you differenciate between that empty string (when doing
"read(0)"), from EOF (that is signaled by an empty string)?.
If you need to be able to make that distinction, then
you have to be careful not to try to read 0 bytes.
Personally I've never come across a situation w
Jesus Cea wrote:
My point is: we are simplifying the program considering "0" a valid len
counter, but we complicates it because now the code can't consider "" =
EOF if it actually asked for 0 bytes.
What are you suggesting read(0) *should* do, then?
If it returns None or some other special val
Terry Reedy wrote:
An alternative to manipulating PATH would be to make and add to the
Start Menu a Command Prompt shortcut, call it Command Window or
something, that starts in the Python directory.
That doesn't seem very satisfactory, because the user
is going to want to work in the director
M.-A. Lemburg wrote:
The problem is: how to undo those changes without accidentally
undoing an explicit change made by the user ?
Is that really much of an issue? If the PATH contains an
entry corresponding to the Python installation that's
being uninstalled, then it's not going to work once t
1601 - 1700 of 2443 matches
Mail list logo
