[EMAIL PROTECTED] wrote:
> Hey guys:
>
[(i,j,k) for i in range(1,j) for j in range(1,k) for k in range(1,5)]
> [(1, 1, 1), (1, 1, 2), (1, 1, 3), (1, 1, 4), (1, 2, 1), (1, 2, 2), (1,
> 2, 3), (1, 2, 4), (1, 3, 1), (1, 3, 2), (1, 3, 3), (1, 3, 4), (2, 1,
> 1), (2, 1, 2), (2, 1, 3), (2, 1, 4),
Dima Barsky wrote:
> Carl Waldbieser <[EMAIL PROTECTED]> wrote:
>
>> Does anyone know of any good examples for writing client side code
>> to upload files over a secure FTP connection? I am referring to
>> FTPS, *not* SFTP, which I found out the hard way are two
rgs):
use(kwargs['x'])
class B(object):
def __init__(self,**kwargs):
use(kwargs['y'])
class C(A,B):
def __init__(self,**kwargs):
super(C,self).__init__(**kwargs)
C(x=1,y=2)
> I'm probably overlooking some basic stuff here
iness. For
instance, a foolproof way to avoid name clashes in mixin classes would
require a complete overhaul of namespaces in Python, and that is not
going to happen.
At best, what you might get is some sort of protocol (maybe a
decorator) that standardizes calling the base class methods, coupled
with a very strong suggestion to use it in all future code for all
classes.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ng, based on the description, and it's not like th BDFL
to throw out keywords for things that current syntax can handle. It
leads me to suspect that maybe he has something up his sleeve. Hmm.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
. >>> "abcd".encode("base64")
This is an encoding between two byte strings.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
other.
The Zen of Python says that "simple is better than complex" and
"complex is better than complicated". Java does pretty well here. C++
didn't even get "complicated is better than convoluted" right. There's
are a ton of flaws in C++ not found in Ja
r types",
which is not what you're doing, so it doesn't apply here. For built-in
types, iterators are at work. The list iterator probably doesn't even
call getitem, but accesses the items directly from the C structure.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
it'll proceed to
compare the objects themselves, which could throw an exception.
Stick the index in there, and that possibility is gone.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
r for each loop (since it's physically outside the loop
part).
One question: what do you do with a variable bound inside a while-block
that has the same name as a local variable? (Or, horrors, a
surrounding while-block?) I'm inclined to think it should be illegal,
but maybe it would be too restrictive.
Anyways, I like this idea a lot.
+1
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
you will. Under this suggestion, there
would be modified versions of various simple statements.
This wouldn't be a problem parsing, of course, because "where" would be
a keyword.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
for
clarification ;-)
That's ok. For it fly, it's got to be able to withstand the flak.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > You misunderstand.
BTW, Peter, I guess I should have said "I misunderstand, but it can be
legal if you consider it part of the statements", since it appears the
author did intend it to be part o
the if-expression and the if-block.
It (or your suggestion) could work with a while-loop too.
. while line where line=f.readline():
. do_something_with(line)
The main problem here (as some would see it) is that you can't do
something this:
. if m > 20 where (def m(): a(); b()):
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Nick Coghlan wrote:
> Carl Banks wrote:
> > What if the condition you wanted to test wasn't the same as the
thing
> > you want to save? In other words, how would you convert this?
> >
> > . where:
> > . m = something()
> > . if m > 20:
> &
expression, then m would have to be either be visible within
the whole surrounding scope, or just within that expression.
What I proposed was really nothing more than a convenient way to sneak
an extra binding inside an elif clause. (The real point here is not to
use this on if-clauses, but on elif-clauses.)
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
of LISP supports the Zen of
Python.
If I wanted to use LISP, I'd be using LISP. But I like my statements
and expressions distinct. I like things that belong in statements to
stay in statements, and things that belong in expressions to stay in
expressions.
And a suite, be it a def statement,
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > And a suite, be it a def statement, a where block, or whatever,
belongs
> > in a statement, not an expression.
>
> So do you approve of the movement to get rid of the print statement?
Any li
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > > So do you approve of the movement to get rid of the print
statement?
> >
> > Any little incremental change in Python you could make by having or
not
> > having a print stat
; it looks to me like the dogma is +12 for macros. What are your
thoughts?
Paul,
When I asked you to do this, it was just a rhetorical way to tell you
that I didn't intend to play this game. It's plain as day you're
trying to get me to admit something. I'm not falling for it.
If you have a point to make, why don't you just make it?
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > When I asked you to do this, it was just a rhetorical way to tell
you
> > that I didn't intend to play this game. It's plain as day you're
> > trying to get me to admit something.
to local names becomes the initial value
> of the class __dict__). So, e.g.,
>
> i = i1 = 3
> let:
> i1 = i+1
> from math import sqrt
> in:
> print i1, sqrt(i1)
> print i1,
> print sqrt(i1)
>
> would print
>
>
# chmod 000 /usr/lib/python2.3/site-packages/pysolsoundserver.so
crude but very effective.
carl
--
http://mail.python.org/mailman/listinfo/python-list
It's me wrote:
> The world would come to a halt if all of a sudden nobody understands
complex
> numbers anymore. :-)
Actually, it would oscillate out of control.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
ided
> a few uses, but no formal definition (maybe it's a European phrase so
> searching for it in English is futile). The closest thing I found
was
>
> Or is it another case of Belgian logic, where you believe it
because
> theres no evidence or motive whatsoever?
Maybe
types as required. :)
Ok.
http://www.urbandictionary.com/define.php?term=belgian&r=f
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
rganize the standard library into an intricate feudal hierarchy of
packages, modules, and cross-references." :)
The gist of "Flat is better than nested" is "be as nested as you have
to be, no more," because being too nested is just a mess.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
e a
duck, it's made of wood.)
The flat method of polymorphism is so much better it isn't even funny.
Again, Python chose wisely.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Timothy Fitz wrote:
> On 19 Jan 2005 15:24:10 -0800, Carl Banks
<[EMAIL PROTECTED]> wrote:
> > The gist of "Flat is better than nested" is "be as nested as you
have
> > to be, no more," because being too nested is just a mess.
>
> Which I agree with
erator" (where callable is a name, not a
description), appearing in a different context from where it was coined
that causes us to parse it differently (where callable is a
description, not a name), and accidentally stating an absurdity.
I'd say it's actually a nice bit of subtlety.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
se it, all I can think of is how much better this POS would
be if they had just extended Python (probably would even be faster).
At least they were smart enough to (try to) make it into a complete
programming language.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Roy Smith wrote:
> "Carl Banks" <[EMAIL PROTECTED]> wrote:
>
> > > Imbed
> > EMBED.
>
> My apologies for being sloppy. And with an initial capital, so it
just
> jumps off the page at you :-)
Ok. Prescriptive language isn't normally my cup of t
pest, that his claims are untrue and his advice is not
good, and that he appears that his posts are just trolling in disguise.
(Or, you could do what I do when I feel a need to reply: follow-up with
a Flame Warriors link. For Xah, it would probably be this:
http://tinyurl.com/4vor3 )
--
CARL
eir tendency to rebind variables
too much? Just a thought.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
ntation.
from itertools import *
[ x for (x,s) in izip(iterable,repeat(set()))
if (x not in s,s.add(x))[0] ]
that's-one-ambiguously-better-solution-ly yr's,
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
e does not indiscriminately remove them. zip, though
it feels a little exotic, is very useful and serves a purpose that no
language feature serves(*), so rest assured it's not going to
disappear.
(*) Excepting izip, of course, which is more useful than zip and
probably should also be a builtin.
--
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
(from the procedural point of view).
Jihad? I'd say it's mostly just indifference to the functional
programming cause.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
stic list comp would look something like this in a real program:
[ x**2 + y**2 for (x,y) in izip(xlist,ylist) ]
Now there's no longer much advantage in conciseness for the map version
(seeing that you'd have to define a function to pass to map), and this
is more readable.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Christopher Subich wrote:
> Carl Banks wrote:
>
> > Listcomps et al. cannot do everything map, lambda, filter, and reduce
> > did. Listcomps are inferior for functional programming. But, you see,
> > functional is not the point. Streamlining procedural programs is th
Steven D'Aprano wrote:
> Carl Banks wrote:
>
> > The shamelessness with which you inflated the verbosity of the latter
> > is hilarious.
>
> [snip]
>
> > [ x**2 + y**2 for (x,y) in izip(xlist,ylist) ]
> >
> > Now there's no longer much a
Christopher Subich wrote:
> Carl Banks wrote:
> >
> > Christopher Subich wrote:
> >>I've heard this said a couple times now -- how can listcomps not
> >>completely replace map and filter?
> > If you're doing heavy functional programming, listcomps
Christopher Subich wrote:
> That said, Python itself is mostly a procedural language, with the
> functional tools really being bolted on[1].
[etc., snip]
Yeah, that's pretty much what I said in the first place.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
appreciated!
Thanks,
Andy Carl
--
http://mail.python.org/mailman/listinfo/python-list
y use + on lists (I tend to use list.extend
mostly), and if + had instead been used for element-by-element
operations, I don't think it would have affected the overall quality of
Python too much. But, as it's been said, it's a little late to change
it now.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
name or a file object using isinstance(basestring,x)
on it. But the best thing to do is fix those interfaces, and let path
be what it should be, and not a hack to accommodate poor code.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
id repeat if you're feeling EVIL.
[ x for x in iterable if x not in locals()['_[1]'].__self__ ]
Turning this into a turing machine is left as an exercise. The recipe
in effect:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/204297
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
]
> > [1, 2, 6, 24, 120, 720, 5040, 40320, 362880]
> > >>>
>
> There's no need for repeat:
>
> >>> [state.append(state[-1] * symbol) or state[-1]
> for state in [[1]]
> for symbol in range(1, 10)]
> [1, 2, 6, 24, 120,
all this is a stupidly horrible
circumstance. The circumstance is that an archaic language designed to
be hand-optimized and has unfortuntate importabilities has ever became
everyone's shizzle.
(I'm hating C today; I was asked to write something in C and I can't
use anything else b
ith an exception.
(Ok, I'm actually not curious, cause I'm pretty sure you don't.)
[snip]
> Competition: Has anyone found anything you can't do in the language?
Mr. Turing is rolling in his grave
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
probably
do better to mmap the file (see the mmap module) rather than read it.
And, in case you're wondering: yes it is theoretically possible for
different files to have the same md5. However, the chances are
microscopic. (Incidentally, the SCons build system uses MD5 to decide
if a file has been modified.)
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
llbent on only using lambda, that can be done too:
. setattr(myclass,item,(lambda x:(lambda self:
func(self,x)))(item))
You may not be aware of it, but what you're trying to do is called
"currying"; you might want to search the Python Cookbook for recipes on
it.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
jfj wrote:
> Carl Banks wrote:
> > Ted Lilley wrote:
> >
> >
> >>Unfortunately, it doesn't work. It seems the closure keeps track
of
> >>the variable fed to it dynamically - if the variable changes after
> > [...]
> >>
> >
round a common data
structure, add complexity and hurts performance.
And it's a pretty common situation; a lot of recursive algorithms can
make very good use of this.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
> Say you have a suite of functions, all of which are called by some
main
> function and each other, and all of which need to access a lot of the
> same data. The best, most straightforward way to do it is to have
the
> common data be a local variable of the main f
Mike Meyer wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
>
> > Say you have a suite of functions, all of which are called by some
main
> > function and each other, and all of which need to access a lot of
the
> > same data. The best, most straightforwar
#x27;t yet say contrived, though; I have referenced changing bindings
a few times). Maybe you have a point.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
parentheses, it considers that a tuple.
For example, if you try this with print:
print ("hello","world")
you see that in prints out a tuple value, rather than treating "hello"
and "world" as arguments. Same thing with assert.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
now-you-can-find-all-five-Lagrange-points-ly yr's,
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
> . from Numeric import *
> . from LinearAlgebra import *
> .
> . def quinticroots(p):
> . cm = zeros((5,5),Float32)
> . cm[0,1] = cm[1,2] = cm[2,3] = cm[3,4] = 1.0
> . cm[4,0] = -p[0]
> . cm[4,1] = -p[1]
> . cm[4,2] = -p[2]
> .
er?
Don't use getattr and setattr unless you have to construct the name of
the attribute at run time. That's what they're for.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
s not practical, put myfun into a third module, and
have my_imported_mod import that.
If you want to live dangerously, you could do something like this from
my_main_mod:
import my_imported_mod
my_imported_mod.myfun = myfun
I don't recommend it, though, because my_imported
Steve Holden wrote:
> Carl Banks wrote:
> > Don't use getattr and setattr unless you have to construct the name
of
> > the attribute at run time. That's what they're for.
> >
> Well, they are surely helpful in delegation contexts as well, or do I
> mi
Python, this is easy with Numeric/numarray; pure Python I wouldn't
want to try (that's what Numeric is for), but it's possible.
So we've reduced the problem to brute forcing 2 variables, which is
only 81 combinations; definitely doable.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
make much
sense in Python because of it. However, Python is versatile enough
that you can get something to that effect if you really need it.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
when setting a global. Either this or
gloabls() will work fine. Please don't use eval for stuff like this:
that's not what it's for and it has the potential to be dangerous.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
> Doug Schwarz wrote:
> > I don't see how getattr solves the original problem. What,
exactly,
> is
> > the first argument to getattr?
>
>
> mod = __import__(__this__)
That should be __import__(__name__)
Silly me.
--
CARL BANKS
--
http://
Python, the most straightforward thing to do is write a
small wrapper extension that starts the Python interpretter to do the
dirty work. The dialog box may be easier done in the extension itself
and not in Python subprocess.
For details, google for tutorials on writing Firefox extensions.
--
C
e I wrote. I posted this example here in
comp.lang.python a while back:
http://tinyurl.com/5qgsw
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
le(filename):
. def descriptor(func):
. flo = open(filename)
. try: f(flo)
. finally: f.close()
. return None
. return descriptor
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
> I could, however, see myself
> using the slightly more complicated descriptor such as this (for a
> wholly different reason, though):
>
> . def call_with_open_file(filename):
> . def descriptor(func):
> . flo = open(filename)
&g
at to unify the language, even by dropping
> features.
Yes, fortunately that happens. It's good, too.
> The current snapshot is a transitional Python and thus
> with some double features. The numerical types and two kinds of
> classes are examples. I'm very surprised about
which has created it, think about the loop body spawning a thread.
Yes, it does happen here and there. I've needed to do that in GUI
programming. But I would say it's not remotely as common as it other
uses, and is easy to work around:
> >>> closures = []
> >>> for i in range(10):
> ...def defineadder(y):
> ... def add(x):
> ... return x + y
> ... return add
> ...closures.append(defineadder(i))
> ...
> >>> closures[5](1000)
> 1005
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
"Brandon J. Van Every" <[EMAIL PROTECTED]> writes:
> Last I looked, 2 years ago?, there were no compiled, open source lisps that
> ran on Windows. Has this changed?
I have a virtually completed port of CMUCL to Win32. And, if I was
not busy organizing a Lisp conference, it would be publicly ava
Michele Simionato wrote:
> Carl Banks:
> > If Python did it the way Scheme did, this would be pretty useless.
>
> But notice that Scheme has no problems whatsoever:
>
> (define (toplevel)
> (define a 1)
> (define (f)
> (display a))
> (set! a 2)
>
Marcin 'Qrczak' Kowalczyk wrote:
> The issue is about the semantics of loops: whether they introduce
> a new variable for each iteration, or change the value of a single
> variable.
Yes, I see what you are saying now. Good point.
--
CARL BANKS
--
http://mail.python.o
nting a, and
a.incr(b) looks like it might be adding b to a. I don't like count
because it's too vague; it's pretty obvious what it does as an
iterator, but not as a method of dict. I could live with tally,
though. As for a short name for the other one, maybe fileas or
fileunder?
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
e
uses of threads. There's no complex communication involved; locks and
semaphores and stuff aren't required. Just connect to the database in
a subthread, and have it set a global flag just before it exits.
Animate in a loop in the main thread, checking the flag every
iteration, and when it's true, you're done.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
you can't slice with the parentheses. Because of this, I don't use the
parentheses for things like multidimensional arrays.
I tend to use the parentheses whenever the index is some sort of atomic
value, however.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
port__(__name__)
setattr(mod,symbol,value)
Works perfectly unless you're worried about someone modifying the built
in __import__.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
mixed slices and indices. The
__getslice__/__getitem__ paradigm isn't versatile enough to handle this
situation. In that light, I'd say checking for slices is the lesser
evil.
As for why list objects still use getslice--they probably shouldn't.
I'd file a bug report.
--
CARL
it check whether its
type is list (or str or tuple), and only call __getitem__ if it is not
(i.e., only for subclasses). I don't think that would be too bad.
Subclasses would still be free to override __getslice__, but wouldn't
have to.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
don't think it's a
good idea to deprecate it.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
odify object dicts to get the effect of changing
object attributes from time to time (mostly to take advantage of dict
methods, which I could see being a reason to use globals() as well).
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
decreases the morale in every city of all countries
that have PERL advance but not PYTHON by 50%
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
but a Bunch class neater and more
concise (not to mention less typing).
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
e-scenes
behavior.
I'd say using globals() is far eviler. So I must disagree with your
good-natured objection. Unless there's some practical weakness of
using references that I am unaware of.
--
CARL BANKS
(Yes, I know eviler is not a word.)
--
http://mail.python.org/mailman/listinfo/python-list
perate under the assumption that
zip will be Python 3000 Certified (tm).
Having said that, you might want to consider using itertools.izip
instead. It works just like zip, but returns an iterator instead of a
list. Good for those length-ten-million lists you wanted to iterate
side-by-side.
--
CARL
projecktzero wrote:
> He thinks that OOP has more overhead
I think he's just confusing programming with marriage.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Bengt Richter wrote:
> m=type('',(),{})()
Nick Coghlan wrote:
> Heh.
>
> Look ma, Perlython!
I doubt anyone could perform such a ghastly hack so simply and
straightforwardly in Perl.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
mentions
IPython, or Michele Simionato (sp?) proposes a metaclass solution to a
problem, or Paul Rubin decries any aspect of Python that differs from
Lisp,
or Aahz asserts that the GIL isn't a significant problem in practice,
or
all-in-fun-of-course-ly yr's,
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
st in accord with the design
goals of Python; but in the end, the divends are small compared to
improving other aspects of the language.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
ia past can be
rightfully compared with the masterpieces of millenia past.
Then again, millenia past didn't have Frank Gehry (i.e., the Perl of
modern architecture).
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
ere I
designing my own language, there is no other way I would do it.
Grouping by indentation is a slam dunk for me.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
ow?
Well, Python seems to get along fine without the ability to do
isinstance(foo,file_like_object); probably better off in the end for
it. So I'd say you should generally not do it. Inheritence is for
when different classes need to share functionality.
--
CARL BANKS
--
http://m
. pass
However, I would guess the Python gods wouldn't approve of this use of
StopIteration, and so would make no sacrifices to get it.
Nevertheless, it seems likely to be how a list comprehension would
behave in Python 3.0, so maybe we should do it.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
. So Kindly
> > clear my doubt regarding this
>
> A unary operator has one operand; a binary operator has two operands;
a
> ternary operator has three operands. Python has none built-in,
Not so fast, my friend. What about the expression "0.0 < a < 1.0"?
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
> "Carl Banks" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >> A unary operator has one operand; a binary operator has two
operands;
> >> ternary operator has three operands. Python has none built-in,
> &g
u?
> I don't think
> there are any plans to give venv the functionality of virtualenv,
What functionality do you mean?
> so
> presumably there are people who like it just fine the way it is now.
> They must have very different needs than I do.
I don't know, since you never said what it is about venv that doesn't
meet your needs :-)
Carl
signature.asc
Description: OpenPGP digital signature
--
https://mail.python.org/mailman/listinfo/python-list
On 11/30/2015 10:20 AM, Laura Creighton wrote:
> In a message of Mon, 30 Nov 2015 09:32:27 -0700, Carl Meyer writes:
>>> I think it is only meant to be used by people who want to install
>>> packages but not site-wide, but I am not sure about that.
>>
>> I don&#x
ing may be the python modules like os , shlex etc come
> first and later the user defined modules like import
> plaftform.cluster .etc come latter
>
> Sorry if my question sounds dump , I was running pep8 and don't see
> its bothered much about it
AFAIK the pep8 module doesn
101 - 200 of 2081 matches
Mail list logo
