On Thursday, May 29, 2014 1:15:35 AM UTC-7, Chris Angelico wrote:
> On Thu, May 29, 2014 at 11:20 AM, Carl Banks wrote:
>
> > Most threads have cleanup work to do (such as deleting temporary
> > directories and killing spawned processes).
>
> >
>
>
to
ensure the program doesn't hang.)
This is Python 2.7, and it's only ever going to run on Windows.
Thanks for any advice/warnings.
Carl Banks
--
https://mail.python.org/mailman/listinfo/python-list
VM-to-Javascript project is called emscripten.
https://github.com/kripken/emscripten/wiki
Demo of Python (and a bunch of other languages) here:
http://repl.it/
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
). But if you allow a downstream user to
recreate the generator at will, then the writer will always have to be wary of
adverse side-effects if the generator is iterated through twice.
So, although I can see it being occasionally useful, I'm going to opine that it
is more trouble than it's worth.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Friday, October 14, 2011 6:23:15 PM UTC-7, alex23 wrote:
> On Oct 14, 4:56 pm, Carl Banks
> wrote:
> > But you can see that, fully realized, syntax like that can do much more
> > than can be done with library code.
>
> Well sure, but imaginary syntax can do _anyt
On Friday, October 14, 2011 12:41:26 AM UTC-7, Peter Otten wrote:
> Carl Banks wrote:
>
> > Is it possible to specify a zero-length switch? Here's what I mean.
> >
> > I have a use case where some users would have to enter a section name on
> > the command li
iler is free to execute
asynchronously relative to each other (I'll call it async).
async:
a += 1
f *= a
async:
b += 1
e *= b
async:
c += 1
d *= c
There is utterly no chance of this syntax entering Python.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
it. But you
can see that, fully realized, syntax like that can do much more than can be
done with library code.
Obviously that extra capability is a very long way off for being useful in
CPython.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ince the current behavior of
the above code seems to do nothing useful, it could be added to argparse with
very low risk of backwards incompatibility.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
n try running it on a pty device (if you're on Unix). If
worse comes to worst, see if there's a way to get the external task to print
lots of extra output (a verbosity setting, for instance); that could work in a
pinch until you can debug it more thoroughly.
Carl Banks
--
http://mail
A Dog is whatever it can do. If a Cat is yamlafiable,
then it's coorect to say that a Cat is a Yamlafible (even if a cat isn't).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
I find that I almost
never use mixins, though I have absolutely nothing against them and I use MI
and metaclasses all the time. It's just that for most things I'd use a mixin
for, I find that one or two regular functions work perfectly well.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
han
> you have, just more RAM than you have free. Last time I faced a
> situation like this, I just decided it was better to stick to the
> 32-bit program and let it crash if it got too big.
On my 64-bit Linux system, I got a memory error in under a second, no thrashing.
I have no swap.
ece
of data for the different properties. The API provides a void* so that the
extension writer can pass arbitrary data to the get and set functions.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Friday, September 2, 2011 11:01:17 AM UTC-7, Adam Skutt wrote:
> On Sep 2, 10:53 am, Roy Smith wrote:
> > I have a function I want to run in a thread and return a value. It
> > seems like the most obvious way to do this is to have my target
> > function return the value, the Thread object stas
it has a SQL
extension that allows you to specify error semantics. It looks something like
this:
UPDATE OR IGNORE
UPDATE OR FAIL
UPDATE OR ROLLBACK
I'm not sure exactly how this interacts with pysqlite3, but using one of these
might help it throw exceptions when you want it to.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
evelopers that this stuff would be useful for
positional arugments, too. They just dropped the ball there.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
reak if you need to break further. Something like this, for example:
break_level = 99
while loop1:
while loop2:
while loop3:
if some_condition:
break_level = (1, 2, or 3)
break
if break_level < 3: break
break_level = 99
if break_level < 2: break
break_level = 99
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
eople
that it will behave this way (not to mention it's a lot more useful). It's
only for the less common and much more advanced case of creating a closure in a
loop that the other behavior would be preferred.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ction like coalesce being helpful if you have a list of
several options to check, though. Also, SQL doesn't give you a lot of
flexibility, so coalesce is a lot more needed there.
But for simple arguments in Python, I'd recommend sticking with "if arg is not
None: arg = whatever"
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
an argument to the lambda (v) that accepts the int argument
of the signal. If you don't have that argument there, the int argument goes
into x, which is why Python prints 0 instead of "finished".
Second, processess run asynchrously, and because of line-buffering, IO can
output asynchronously, and so there's no guarantee what order output occurs.
You might try calling the python subprocess with the '-u' switch to force
unbuffered IO, which might be enough to force synchronous output (depending on
how signal/slot and subprocess semantics are implemented).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
could have done something like this:
row = [ float(x) for x in re.findall(r'\d+\.\d+e\+d+',line) ]
And regexp matching is often overkill for a particular problem; this may be of
them. line.split() could have been sufficient:
row = [ float(x) for x in line.split() ]
Of course, thes
nt processes use one mainthread!!
They don't use one main thread; it's just that each process's main thread has
the same name. Which makes sense: when you fork a process all the data in the
process has to remain valid in both parent and child, so any pointers would
have to have the same value (and the -1216477504 happens to be the value of
that pointer cast to an int).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
#x27;.split(os.sep)
> ['C:/windows']
It's not even fullproof on Unix.
'/home//h1122/bin///ghi/'.split('/')
['','home','','bin','','','ghi','']
The whole point of the os.path functions are to take care of whatever oddities
there are in the path system. When you use string manipulation to manipulate
paths, you bypass all of that and leave yourself open to those oddities, and
then you find your applications break when a user enters a doubled slash.
So stick to os.path.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
rg goes down,
and will help keep the load off the server when it's up.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
cumentation that is
> in the 'built-in types' section (which could now be called the
> built-isssn classes section.
Built in functions and contructors?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
the top of my head, I can think of
using functools module to help with logging or to apply patches, whereas in
Java they'd have to resort to a code weaver or lots of boilerplate.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ure codes some mean Python!
That's pretty funny. I knew what it would be even when I saw the cut-off
subject line, and I am too young to remember it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
;, "copyright", "credits" or "license" for more information.
> >>> def foo():
> ... "Docstring"
> ... print __doc__
> ...
> >>> foo()
> None
> >>>
>
> What does yours do?
It prints the module docst
akwebsoft dot com
>
> ## Is it possible to get the module docstring
> ## from the module itself?
print __doc__
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ine. Code objects are also used
directly by the interpreter when executing byte code. A function object is
only one of several "interfaces" to a code object.
A minor reason is that code objects are constant (in fact, any object that is
built at compile time must be a
licit that the default
arguments are executed only once, when creating the function, *not* when
calling it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Saturday, July 2, 2011 6:35:19 AM UTC-7, H Linux wrote:
> On Jul 2, 2:28 am, Carl Banks
> wrote:
> > On Friday, July 1, 2011 1:02:15 PM UTC-7, H Linux wrote:
> > > Once I try to nest this, I cannot get the module to load anymore:
> > > >import smt.bar
>
; PyMODINIT_FUNC
> initbar(void)
> {
> Py_InitModule("smt.bar", bar_methods);
> }
This should be: Py_InitModule("bar", bar_methods);
That's probably it; other than that, it looks like you did everything right.
What does the installed file layout look like after runni
self.set(iterable)
def __iter__(self):
return self
def next(self):
return self.current_iter.next()
def set(self,iterable):
self.current_iter = iter(iterable)
s = IteratorByProxy(xrange(10))
for i in s:
print i
if i == 6:
s.set(xrange(15,20))
Ca
thing.
That is exactly what I fear, and you are wrong that "we all agree that this
would be a bad thing". Several people in this thread are arguing that
inheriting docstrings by default is the right thing, and that would lead to
heaps of inappropriate documentation.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Friday, June 10, 2011 2:51:20 AM UTC-7, Steven D'Aprano wrote:
> On Thu, 09 Jun 2011 20:36:53 -0700, Carl Banks wrote:
> > Put it this way: if Python doesn't automatically inherit docstrings, the
> > worst that can happen is missing information. If Python does inher
cstrings, part of that
bargain is that the language will go out of its way to support flat-out wrong
docstrings, and that trumps any ostensible benefit.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
he worst
that can happen is missing information. If Python does inherit docstrings, it
can lead to incorrect information.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Thursday, June 9, 2011 6:42:44 PM UTC-7, Ben Finney wrote:
> Carl Banks
> writes:
>
> > Presumably, the reason you are overriding a method in a subclass is to
> > change its behavior; I'd expect an inherited docstring to be
> > inaccurate more often than not
wever, I'd be +1 easily on a little help from the language to explicitly
request to inherit the docstring.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
docstring(base):
def set_docstring(f):
f.__doc__ = getattr(base,f.func_name).__doc__
return f
return set_docstring
where you have to repeat the base class every time:
class Bar(Foo):
@inherit_docstring(Foo)
def somefunction(self):
pass
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
change its meaning from one iteration to the next,
> so a complete name lookup is required at each iteration. This is very
> useful sometimes, but affects performance a lot.
It's main affect performance is that it prevents an optimizer from inlining a
function call(wh
On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D'Aprano wrote:
> On Tue, 31 May 2011 19:45:01 -0700, Carl Banks wrote:
>
> > On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> >> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
> &g
On Wednesday, June 1, 2011 11:10:33 AM UTC-7, Ethan Furman wrote:
> Carl Banks wrote:
> > For instance, say you are using an implementation that uses
> > floating point, and you define a function that uses Newton's
> > method to find a square root:
> >
> >
On Wednesday, June 1, 2011 10:17:54 AM UTC-7, OKB (not okblacke) wrote:
> Carl Banks wrote:
>
> > On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> >> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
> > Python has several non-integer number types
On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks
> wrote:
> > I think you misunderstood what I was saying.
> >
> > It's not *possible* to represent a real number abstractly in any digital
> >
On Tuesday, May 31, 2011 8:05:43 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks
> wrote:
> > On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
> >> Okay, here's a question. The Python 'float' value - is it meant to
er"?
The former. Unlike the case with integers, there is no way that I know of to
represent an abstract real number on a digital computer.
Python also includes several IEEE-defined operations in its library
(math.isnan, math.frexp).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
>
> > Floating point arithmetic evolved more or less on languages like Fortran
> > where things like exceptions were unheard of,
>
> I
On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote:
> On Mon, May 30, 2011 at 10:55 AM, Carl Banks
> wrote:
> > If exceptions had commonly existed in that environment there's no chance
> > they would have chosen that behavior; comparison against NaN (or any
ver be used as a dictionary key
or in a set (of course).
If it weren't for compatibility with IEEE, there would be no sane argument that
defining an object that is not equal to itself isn't a bug. But because
there's a lot of code out there that depends on NaN != NaN, Python has to
tolerate it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
to handle exceptional conditions.
The only reason to keep NaN's current behavior is to adhere to IEEE, but given
that Python has trailblazed a path of correcting arcane mathematical behavior,
I definitely see an argument that Python should do the same for NaN, and if it
were done Python would be a better language.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
\b # beginning of line
> (?P\w+) # a word
> \s+# some whitespace
> (?P=word)(?!\w)# the same word again
>"""
> double_word_re = re.compile(pattern, re.I | re.X)
Perl has the X fla
er looks pretty useless for .startswith() and
is probably only present for consistency with other string search methods like
.index(). Yet on .index() using None as an argument works as intended:
>>> "cbcd".index("c",None,None)
0
So it's there for consistency, yet is not consistent.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e I
don't have Python 3 handy to test it, but as far as I can tell it will.)
It's just one of the quirks of Python's type system.
I don't agree with Ian's recommendation not to use super() in general, but I'd
probably agree that one should stick to using it only in its intended way (to
invoke base-class methods directly).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
list tells us
nothing. In any case it's ridiculous to claim envy as factor nowadays, as
Python is clearly on the rise while Perl is on the decline. Few people are
choosing Perl for new projects.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
sually
catch StopIteration whenever calling send() or next() by hand. Untested:
result = None
while True:
try:
item = provider.send(result)
except StopIteration:
break
try:
consumer.handleItem(item)
except:
result = 'failure'
else:
result = 'success'
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Friday, April 29, 2011 2:44:56 PM UTC-7, Ian wrote:
> On Fri, Apr 29, 2011 at 3:09 PM, Carl Banks
> wrote:
> > Here is my advice on mixins:
> >
> > Mixins should almost always be listed first in the bases. (The only
> > exception is to work around a technicali
On Thursday, April 28, 2011 6:43:35 PM UTC-7, Ethan Furman wrote:
> Carl Banks wrote:
> > The sorts of class that this decorator will work for are probably not
> > the ones that are going to have problems cooperating in the first place.
> > So you might as well just use
y in base.__dict__.keys():
u[key] += 1
for key in dct.keys():
u[key] += 1
if any(u[key] > 1 for key in u.keys()):
raise TypeError("base classes and this class share some class
attributes")
return type.__new__(metatype,na
dler, and it is incorrect to say it is not. The
call to HomeHandler does create an instance of BaseHandler.
The Python language itself validates this usage. isinstance(test,BaseHandler)
returns True.
If you are looking for a term to indicate an object for which type(test) ==
BaseHandler, then I would suggest "proper instance". test is an instance of
BaseHandler, but it is not a proper instance.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
be possible but not too practical or likely.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
in reason they're not builtin is that they aren't
really that simple. The functions make use of a lot of knowledge
about Python types. Builtins tend to be for straightforward, simple,
building-block type functions.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e to on sorting
time." (Fits your criterion "performs really badly when done so".)
3. You evidently also overlooked the use-case example posted on Python-
dev that you followed up to.
Call me crazy, but you seem to be overlooking a lot of things in your
zeal to prove your point.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
also
want to avoid boilerplate of binding all of them explicitly.
Not a common use case, but it happens. (I've faced it several times,
but the things I work on make it more common for me. I bit the bullet
and wrote out the boilerplate.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
an just write their own cmp
function, and as an added bonus they can work around any peculiarities
with an incomplete comparison set.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 23, 1:38 pm, Paul Rubin wrote:
> Carl Banks writes:
> > It's kind of ridiculous to claim that cmp adds much complexity (it's
> > maybe ten lines of extra C code), so the only reason not to include it
> > is that it's much slower than using key.
>
&
On Mar 23, 10:51 am, Stefan Behnel wrote:
> Carl Banks, 23.03.2011 18:23:
>
>
>
>
>
> > On Mar 23, 6:59 am, Stefan Behnel wrote:
> >> Antoon Pardon, 23.03.2011 14:53:
>
> >>> On Sun, Mar 13, 2011 at 12:59:55PM +, Steven D'Aprano wrote:
&g
a clever key function or an
adapter class than the 0.2 seconds I'd save to on sorting time.
Removing cmp from sort was a mistake; it's the most straightforward
and natural way to sort in many cases. Reason enough for me to keep
it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
agree with
you. But it's ok, it's not unreasonable to call attention to (actual)
bugs here.
I was surprised, though, when several people confirmed but no one
reported it, especially since it was a crash, which is quite a rare
thing to find. (You should feel proud.)
Carl Banks
--
:\python32\python bug.py
>
> generates a popup:
>
> python.exe - Application Error
> The exception unknown software exception (0xcfd) occurred in the
> application at location 0x1e08a325.
>
> Click on OK to terminate the program
> Click on CAN
to inline
functions for potentially big speed increases. It can't do that now
because the name of the function can always be rebound to something
else.
BTW, a function object is definitely mutable.
def squared(x):
return x*x
squared.foo = 'bar'
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 3, 7:12 pm, Carl Banks wrote:
[snip]
Accidental post before I was done. To complete the thought:
I actually can think of one indeterminate behavior in C (although it's
not certain whether this qualifies as interaction with the
environment):
int main(void) {
int a;
printf(
On Mar 3, 5:16 am, Neil Cerutti wrote:
> On 2011-03-03, Tom Zych wrote:
>
> > Carl Banks wrote:
> >> Perl works deterministically and reliably. In fact, pretty much every
> >> language works deterministically and reliably. Total non-argument.
>
> > We
ally and reliably, doesn't mean the rest of us
> shouldn't.
Perl works deterministically and reliably. In fact, pretty much every
language works deterministically and reliably. Total non-argument.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ypes it means "this is a value of this
type as opposed to None". That causes conflicts when more than one of
those tests makes sense for a given type, as it does with Elements.
This change is only for ElementTree as far as I know. (Incidentally,
Numpy arrays are another notable type that's disabled implicit
booleans, but it did it a long time ago.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ference, it does increase the reference
count.
I don't know if there's a simple rule to know of a function borrows or
creates a new reference; I've never noticed one.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
pes. But I don't want a derived class to
overwrite its parent's entry in the subtype dict--it should define its
own key.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
s metaclasses useful
depends on them breaking expectations with respect to ordinary
classes, so I don't think it would be wise to label every divergence a
bug.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ction to help create your closure:
def create_menu_command(j):
def f():
do_something_that_depends_on(j)
return f
for k in x:
menu.add_command(label=str(k),command=create_menu_command(k))
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 9, 3:11 pm, Rouslan Korneychuk wrote:
> On 02/09/2011 04:58 PM, Carl Banks wrote:
> > On Feb 9, 1:14 pm, Rouslan Korneychuk wrote:
> >> On 02/09/2011 02:42 PM, Carl Banks wrote:
> >>> This is the only case I can think of where the
> >>> layout
Just
wrap each C++ class, regardless of its ancestry, in a Python class
with only object as base.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 9, 1:14 pm, Rouslan Korneychuk wrote:
> On 02/09/2011 02:42 PM, Carl Banks wrote:
> > This is the only case I can think of where the
> > layout conflict would be caused by a type setting tp_dictoffset.
>
> No, actually I have code that is roughly equivalent to the f
t has methods
that reference the dict)--just be sure to set it in the first class
that's concrete.
> Also is it possible to have a class that doesn't have these dictionaries
> derive from a class that does?
Nope. That would *really* violate Liskov substitution principle.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
the reference counting altogether, and that was considered too
drastic a change.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
tion of
arguments.
def create_user_form(name,fields,_model):
class Meta:
model = _model
dct = { 'Meta': Meta }
for field in fields:
dct[field] = forms.CharField(max_length=100,
> initial=monitor1.default_limit)
return type(name,(ModelForm,),dct)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
By a lot.
Advanced is not the same thing as complex.
In this particular case I'd say the recommendation to do something
else is a good one, but it's not true in general.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
erl code, all I'm trying to do is
> loop through some dig output of a DNS zone transfer. There are two
> conditions I need to test: whether it's an A or CNAME record. Ultimately, I
> need to assemble the data into a single line listing first the canonical
> hostname (A
line) loop through the output while testing for the matches on the two
> regular expressions. Thank you.
You may have called read() instead of readlines().
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ink something
like this will do it:
import pydoc
print pydoc.render_doc(sys.modules[__name__])
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
sn't fit signature, so do nothing
pass
Personally, I have my doubts about the method in general. It's
definitely preferrable in many cases (like opening a file, where it
avoids a race condition) but for something like this I don't see it
working out too well. But I'm just throwing it out there.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ugh need that someone's figured out
an easy way to handle it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
uch more readable with the
operator on the following line, not even close.
I'm starting to not fold lines with parentheses as much, either.
Sometimes the parentheses break the flow too much, or suggest grouping
where it isn't desirable.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
mail.message_from_string("Subject: blah\r\n
> >>> blah").get('SUBJECT')
> 'blah\r\n blah'
> >>> email.message_from_string("Subject: blah\r\n
> >>> blah").get('SUBJECT')
> 'blah\r
On Jan 20, 9:55 am, Bob Kline wrote:
> On 1/20/2011 12:23 PM, Carl Banks wrote:
>
>
>
> > On Jan 20, 7:08 am, Bob Kline wrote:
> >> I just noticed that the following passage in RFC 822:
>
> >> The process of moving from this folded multiple-l
and
To: "Joe & J. Harvey"
, JJV
@BBN
and
To: "Joe &
J. Harvey" , JJV @ BBN
The process of moving from this folded multiple-line
representation of a
EP 3147 says it now always uses __pycache__.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
way. Most other times
when something can happen on one end of a sequence or another, it uses
different function calls. E.g.: startswith vs endswith, lstrip vs
rstrip, and even pop vs popleft.
Oddly, Hettinger seems to be a big advocate of not overloading
functions.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 17, 10:17 am, jmfauth wrote:
> That's life, unfortunately.
Also, an earlier version of the proposal was to create a *.pyr
directory for each *.py file. That was a real mess; be thankful they
worked on it and came up with a much cleaner method.
Carl Banks
--
http://mail.py
1 - 100 of 1709 matches
Mail list logo
