code as a single function, as it
implements (AFAICS) an entire lexer. It resembles data more than
anything else, and data presumably is allowed to be scrolled. Otherwise
things would be very restrictive!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
function F, they really belong as local functions in F. That makes it
even bigger and more complex, although access to F's locals is simplified.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
I would normally expect enumerated values to be immutable and
hashable,
And, perhaps, to be actual enumerations. (So that in the set (a,b,c,d),
you don't know nor care about the underlying values, except that they
are distinct.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 28/04/2016 10:34, g.v.aar...@skct.edu.in wrote:
start_list = [5, 3, 1, 2, 4]
square_list = []
# Your code here!
for square_list in start_list:
x = pow(start_list, 2)
square_list.append(x)
square_list.sort()
print square_list
TypeError: unsupported operand type(s) for ** or pow(): 'l
ywhere.com/ex/001.html";, "D:/file.html")
in VBS too. (The forward slash in the file name ought to work.)
(I don't know VBS; I assume it does /have/ subroutines? What I haven't
factored in here is error handling which might yet require more coding
in VBS compared with Python)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
=0; i
The limited variable scoping is the only thing missing,
That's just part of a general feature of C where each block can have its
own scope. So you can have dozens of 'i' variables within each function,
provided each is defined in a separate block. (I couldn't see the point
of that either!)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 03/06/2016 02:05, Lawrence D’Oliveiro wrote:
On Friday, June 3, 2016 at 8:52:52 AM UTC+12, BartC wrote:
One major objection was that C's 'for' isn't really a for-statement at
all (as it is understood in most other languages that haven't just
copied C's versi
On 03/06/2016 03:47, Lawrence D’Oliveiro wrote:
On Friday, June 3, 2016 at 8:52:52 AM UTC+12, BartC wrote:
Simple iterative for-loops are more of a DIY effort...
There is one case that Python handles more nicely than C. And that is iterating
over a fixed set of values. E.g. in Python
On 03/06/2016 17:22, Lawrence D’Oliveiro wrote:
On Friday, June 3, 2016 at 9:33:32 PM UTC+12, BartC wrote:
On 03/06/2016 03:47, Lawrence D’Oliveiro wrote:
On Friday, June 3, 2016 at 8:52:52 AM UTC+12, BartC wrote:
Simple iterative for-loops are more of a DIY effort...
There is one case that
the box
and "x" immediately outside:
x:[99]
instead of:
x:[0x12345] -> 0x12345:[99]
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
ly show
the name "b". And it would be ludicrous to suggest that here:
pass# 1
a = 0 # 2
pass# 3
"a" doesn't exist at all at line 1 or at the start of line 2, and only
comes fully into existence by line 3. "a" exists by name in the
byte-code a
t a named variable:
a := (10,20,30,40,50)
c := ^a[3]
println c^ # 30 (was 1-based)
c^ := 77
println a # (10,20,77,40,50)
And here is the above example:
a := 42
b := 17
c := ^a
c^ := ^b
println a # refvar: 21A16F0
println a^ # 17
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
27; reference allows a complete replacement of what it refers
to. That would mean being able to do:
B = "Cat"
print A # "Cat"
No tricks involving in-place updates such as assigning to list elements
are needed.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 08/06/2016 12:01, Antoon Pardon wrote:
Op 08-06-16 om 12:33 schreef BartC:
But a 'proper' reference allows a complete replacement of what it
refers to. That would mean being able to do:
B = "Cat"
print A # "Cat"
No tricks involving in-place upd
On 08/06/2016 15:18, Antoon Pardon wrote:
Op 08-06-16 om 14:34 schreef BartC:
So you have partial updates and full updates. A proper reference will
be able to do both via the reference. Python can only do a partial
update and the reason is that the reference points to the object, not
the
On 09/06/2016 08:50, Antoon Pardon wrote:
Op 08-06-16 om 19:29 schreef BartC:
I don't see why we should determine what a /proper/ reference
can do, based on what it does in one specific language.
Because there are some things that such references can do that Python
can't do with
going leash, compared to tying an incoming
one. Just like the puppies have necks to tie incoming leashes to (via
collars to avoid cruelty) and mouths for out-going ones.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 09/06/2016 10:55, Antoon Pardon wrote:
Op 09-06-16 om 11:10 schreef BartC:
On 09/06/2016 08:50, Antoon Pardon wrote:
Op 08-06-16 om 19:29 schreef BartC:
I don't see why we should determine what a /proper/ reference
can do, based on what it does in one specific language.
Because
Python object references work like the registration (license) plate on a
car. Whatever you do via that, it will be the same car.
Full references require the address of the house.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 09/06/2016 12:19, Antoon Pardon wrote:
Op 09-06-16 om 12:53 schreef BartC:
On 09/06/2016 10:46, Antoon Pardon wrote:
Op 09-06-16 om 09:36 schreef Steven D'Aprano:
Your example demonstrates object mutation, not assignment.
Generally assignment and mutation don't contradict
On 09/06/2016 12:08, Antoon Pardon wrote:
Op 09-06-16 om 12:48 schreef BartC:
What does it matter?
If swap() can be implemented via such a function, then it means that
the language has such capability, which can be useful in different
scenarios.
If it can't, then the language hasn'
ll refer to the same data. But assignment to either - not an in-place
mod - will break the connection).
Your code could be rewritten as:
from Test import some_function, my_print
import Test
some_function()
my_print()
print(Test.test_var)
Anyway, it shows Python doesn't have true cross-modu
On 12/06/2016 20:25, Ned Batchelder wrote:
On Sunday, June 12, 2016 at 3:08:01 PM UTC-4, BartC wrote:
On 12/06/2016 00:44, Marcin Rak wrote:
from Test import some_function, my_print
from Test import test_var
some_function()
my_print()
print(test_var
e tools may be able to pick that up.
(Another kind of error (C seems to have plenty of capacity in this
regard!) is forgetting the */ in a /* ... */ comment. Then code is
mysteriously ignored until the end of the next /* ... */ comment.
Although a syntax-highlighting editor will pick that u
tion call is skipped.)
If that's not enough, then 'return' in most languages will let you
return early from a routine, skipping the rest of the function.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 19/06/2016 15:35, Antoon Pardon wrote:
Op 12-06-16 om 23:10 schreef BartC:
On 12/06/2016 20:25, Ned Batchelder wrote:
Just as here there is no link between x
and y:
x = 12
y = x
(And that's a good illustration of why 'y' isn't a name reference to &#
On 19/06/2016 18:16, Joel Goldstick wrote:
People who understand global variables generally avoid using them at
all costs.
Then perhaps they don't understand that in Python, top-level functions,
classes and imports are also globals.
--
Bartc
--
https://mail.python.org/mailman/lis
ython
couldn't) weren't name references at all; (2) that Python really did
have name references when you tried hard enough to emulate them.
What sort of semantic games were those then?
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
; is a run-time argument of
'exec()'.
And one big advantage of Python is being able to try different things
and run them instantly. It sounds like you will be using a complicated
tool-chain performing a series of transformations, or does that all
happen instantly too?
--
Bartc
--
https:
odule-scope names in some modules that are not intended to be
exported.
The 'from' mechanism deals with that, by creating an alias to the
/value/ of an exported name without affecting identical names in other
modules, but it has the problem of not being an alias for the name itself.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 22/06/2016 01:24, Rick Johnson wrote:
On Tuesday, June 21, 2016 at 6:16:09 PM UTC-5, BartC wrote:
I tried using your method but it didn't work:
...you'll find a thread i authored, that includes an object
exposing a global namespace named "G". Details of how to
inj
oad a ready-to-run binary release and
not try and build it from sources which I understand is not trivial.)
Google for 'python download for windows'. You're looking for a
self-installing executable or a .msi file.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
edicated statement for an endless loop, so you have to use 'while True'
or 'while 1'.
(Well, the loop is only endless until you do an explicit exit out of it,
such as using 'break'.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 23/06/2016 12:39, Chris Angelico wrote:
On Thu, Jun 23, 2016 at 8:15 PM, BartC wrote:
Actually pretty much any expression can be used, because Python can
interpret almost anything as either True or False. Don't ask for the rules
because they can be complicated, but for example, ze
A != B
should be equivalent to
A = A ! B
Yes, that's an another inconsistency in C. Sometimes "<>" was used for
"not equals", or "≠" except there was limited keyboard support for that.
("/=" would have the same problem as "!="
quot; would be
parsed as "aeqb".)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 26/06/2016 16:41, MRAB wrote:
On 2016-06-26 11:48, BartC wrote:
However, why couldn't Python have used "=" both for assignment, and for
equality? Since I understand assignment ops can't appear in expressions.
[snip]
Python supports chained assignments. For example, &
On 27/06/2016 00:22, Gregory Ewing wrote:
BartC wrote:
On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
One of Python’s few mistakes was that it copied the C convention of
using “=” for assignment and “==” for equality comparison.
One of C's many mistakes. Unfortunately C has been
t a bug. :)
That's not wise. It could have worked by chance. And putting in the
parentheses anyway means the fragment of code stays interchangeable with C.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
also think can be a bit of a cheat when trying to
compare benchmarks, but that's another matter). Unique features, which
can include just using a built-in library call to do the work, don't
translate so easily!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
he name is "format".
I suppose the compiler could decide to backtrack and re-parse based on
the knowledge that is one or the other, but that's a messy way of doing it.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 28/06/2016 01:11, Dennis Lee Bieber wrote:
On Tue, 28 Jun 2016 00:08:00 +0100, BartC declaimed the
following:
You just design the compiler to do the same processing in each case, ie.
parse a followed (), then mark the result AST
fragment as either an Array term, or Format statement
However, because the language is zero-based, this would have been better
written as:
num_words = len(words)
while counter < num_words: # or just while counter < len(words)
That's if you had to write it as while loop. With the for=loop version,
these details are taken care of behind the scenes.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
that helps; I've never heard of an induction variable.
And according to the first example in that link, then 'word' in the OP's
second example might be classed as an induction variable too! Confusing.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
extremely efficient string handling, we know that
low-level string ops normally take longer than low-level integer ops.
So maybe small-integer handling already had enough overhead that
implementing them as small BIGNUMs didn't make much difference, but it
simplified the lang
On 29/06/2016 10:56, Lawrence D’Oliveiro wrote:
On Wednesday, June 29, 2016 at 9:49:23 PM UTC+12, BartC wrote:
Even if Python has extremely efficient string handling, we know that
low-level string ops normally take longer than low-level integer ops.
Maybe part of the general principle that
job of managing a
12-second time using a composite integer/bigint type.
However, the vast majority of integer code /can be done within 64 bits/.
Within 32 bits probably. But like I said, it's possible that other
overheads come into play than just the ones of using bigints, which I
woul
On 29/06/2016 14:35, Chris Angelico wrote:
On Wed, Jun 29, 2016 at 11:24 PM, BartC wrote:
I used this little benchmark:
def fn():
n=0
for i in range(100):
n+=i
for k in range(100):
fn()
Add, up the top:
try: range = xrange
except NameError: pass
Otherwise, your
would work until I tried it and it didn't:
class C():
def fn():
print ("Hi!")
C.fn()
The error message suggests Python knows what's going on. So why not just
make it work?
(The main issue would be, if an instance X of C /was/ created, then
X.fn() wouldn'
names and which are operators.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
operator
precedence as well. So you could no longer use a recursive-descent parser.
That wouldn't be a problem provided the new operator symbol and its
precedence is known at a compile time, and defined before use.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
e unwieldy?
Python has a simple solution to that:
a = mod.a
b = mod.b
Except that then
a = 0
doesn't do the same thing as:
mod.a = 0
But it'll probably work for things that are not assigned to.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 04/07/2016 01:24, Lawrence D’Oliveiro wrote:
On Monday, July 4, 2016 at 12:17:47 PM UTC+12, BartC wrote:
On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:
On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
Python lacks a mechanism to add user-defined operators. (R has this
On 04/07/2016 03:30, Steven D'Aprano wrote:
On Mon, 4 Jul 2016 10:17 am, BartC wrote:
On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:
On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
Python lacks a mechanism to add user-defined operators. (R has this
capability.) Maybe
On 04/07/2016 02:15, Lawrence D’Oliveiro wrote:
On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote:
The structure of such a parser doesn't need to exactly match the grammar
with a dedicated block of code for each operator precedence. It can be
table-driven so that an operator prece
On 04/07/2016 13:47, Ned Batchelder wrote:
On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
On 04/07/2016 03:30, Steven D'Aprano wrote:
You're still having problems with the whole Python-as-a-dynamic-language
thing, aren't you? :-)
Most Pythons seem to pre-comp
On 04/07/2016 15:46, Ned Batchelder wrote:
On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote:
On 04/07/2016 13:47, Ned Batchelder wrote:
This is a huge change.
I've used a kind of 'weak' import scheme elsewhere, corresponding to C's
'#include'.
I t
run it using:
python prog.py
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
s of the application.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
+3.0/2-0.5
and so on. No other Python code is needed.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
mandatory.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
what was meant:
for x in sequence:
print("Something")
end
print("Something else")
(And no speculation at all if 'end' was mandatory. Python already
provides 'else' (and 'except'?) which can do a similar job in some
circumstances.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 23/07/2016 16:55, Steven D'Aprano wrote:
On Sun, 24 Jul 2016 12:06 am, BartC wrote:
pass can only do so much. If doesn't help here:
for x in sequence:
print("Something")
print("Something else")
Was the second print meant to be indented as well or n
On 24/07/2016 11:35, BartC wrote:
On 23/07/2016 16:55, Steven D'Aprano wrote:
In any case, using "end" instead of "pass" is a poor tradeoff. Instead of
needing to use "pass" (say) one time in a thousand when it is needed, you
would need to use "end
On 24/07/2016 11:45, BartC wrote:
On 24/07/2016 11:35, BartC wrote:
'end' to terminate a block can be emulated of course:
end=0
def fn(a):
if a<=1:
return 1
else:
return fn(a-1)
end
end
Actually this is a good example of how tabs can go wrong (and
On 24/07/2016 14:24, Chris Angelico wrote:
On Sun, Jul 24, 2016 at 11:09 PM, BartC wrote:
Actually this is a good example of how tabs can go wrong (and how the tab
system /is/ fragile - sorry but it is).
I almost certainly wrote the above using 4 and 8 spaces for the tabs, except
for the
On 24/07/2016 13:17, Steven D'Aprano wrote:
On Sun, 24 Jul 2016 08:35 pm, BartC wrote:
Given an otherwise correctly typed program that compiles with no errors,
then it is very easy (if Backspace or Delete is inadvertently pressed
for example), for an indent to disappear without your not
On 24/07/2016 15:51, Chris Angelico wrote:
On Mon, Jul 25, 2016 at 12:44 AM, BartC wrote:
Your attention is diverted, you're doing something on your desk, but you hit
one of the keys by mistake. You might have pressed Delete or you might not.
You look at the screen which has a 5000
On 24/07/2016 20:00, Chris Angelico wrote:
On Mon, Jul 25, 2016 at 4:14 AM, BartC wrote:
A skilled craftsman in any field will choose to use quality tools.
Materials (ie. languages) are important too.
So why do you use
"dumb editor" as a line of argument, rather than getting
On 24/07/2016 22:08, Chris Angelico wrote:
On Mon, Jul 25, 2016 at 6:03 AM, BartC wrote:
Perhaps because I prefer to use my own languages and I don't have anyone
writing the specialist tools for me that would be necessary.
So because you've chosen to use your own language
On 25/07/2016 01:40, Gregory Ewing wrote:
BartC wrote:
So I still think it's fragile, meaning you have to take a lot of extra
care.
The practical experience of a very large number of Python
programmers suggests that it requires very little additional
care over and above that nor
On 25/07/2016 02:04, Gregory Ewing wrote:
BartC wrote:
(They don't need to be elaborate to start being confusing. Take 'int
*a[]' and 'int (*a)[]'; one of these is an array of pointers, the
other a pointer to an array. Quite different! But which is which?
Where have y
On 25/07/2016 03:37, Steven D'Aprano wrote:
On Mon, 25 Jul 2016 08:13 am, BartC wrote:
A solid end-of-block symbol (as you get with 'else' and 'except' because
then you KNOW that's the end of that block) would have been welcome with
the Python indent scheme.
A s
On 25/07/2016 15:36, Random832 wrote:
On Sun, Jul 24, 2016, at 18:13, BartC wrote:
[About C type specs]
I've replied briefly here as this is off-topic now:
http://pastebin.com/ZfcHqpXK
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 26/07/2016 08:21, Gregory Ewing wrote:
BartC wrote:
(Yes everyone uses T*a (pointer to T) instead of T(*a)[] (pointer to
array of T), because, thanks to how C mixes up deferencing and
indexing, the former can be accessed as a[i] instead of (*a)[i].
But it's wrong, and leads to errors
On 29/07/2016 12:14, D'Arcy J.M. Cain wrote:
On Fri, 29 Jul 2016 10:58:35 +0200
Antoon Pardon wrote:
As BartC already mentions it happens fairly often during debugging.
Something like.
try:
Some code
except Some_Exception:
# Commented code for when I am debugging
pass
I re
That's untidy, as is your suggestion to keep the dummy statement lying
around anyway so that the number of statements will always be N+1 and
can never reach 0 as N changes.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 30/07/2016 04:35, Steven D'Aprano wrote:
On Sat, 30 Jul 2016 06:19 am, BartC wrote:
The language requires that blocks always contains 1 or more statements.
Fair enough, except that 0 statements are often needed
They really aren't.
The standard library uses more "pass&q
fit from!
Newline control should be one of the simplest things in the language,
part of the very first programs you write.
(Some languages use 'write' or 'writeln', or 'print' or 'println'; what
could be simpler? Or you just explicitly output a "\n" string.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 30/07/2016 13:22, Chris Angelico wrote:
print(*range(10), sep='\n')
0
1
2
3
4
5
6
7
8
9
Beat that, print statement.
for i in range(10): print i
Same number of characters, but a lot less punctuation!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
(64):
table.append(nextbyte(fs))
The range object isn't really necessary, and the 'i' variable doesn't
need to be exposed (as a programmer-accessible, reference-counted variable).
The 'to' construct I also implemented with a single very fast byte-code,
executed once per iteration.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
*
d)
?
Another category is where code is written predominantly side-ways rather
than vertically. (Multiple chained method calls for example, or trying
to express something as a 'one-liner'.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
nt to send an email replace "bc" with "bcas".)
I'm not using a mailing list; I'm posting to usenet.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
design and especially like
discussing syntax.
That's all.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 30/07/2016 16:48, Steven D'Aprano wrote:
On Sat, 30 Jul 2016 11:58 pm, BartC wrote:
The 'i' is superfluous. Why not:
for 10:
Why bother? What's so special about this that it needs dedicated syntax?
No named loop variable to invent, create, maintain, and destroy.
On 30/07/2016 17:15, Rustom Mody wrote:
On Saturday, July 30, 2016 at 8:17:19 PM UTC+5:30, Steven D'Aprano wrote:
On Sat, 30 Jul 2016 09:39 pm, Rustom Mody wrote:
On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote:
On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote:
A
On 31/07/2016 03:10, Steven D'Aprano wrote:
On Sun, 31 Jul 2016 04:46 am, BartC wrote:
No named loop variable to invent, create, maintain, and destroy. No
range object to create, destroy etc. If you're looking for ways for a
language to be more efficient, then why disregard this p
ready perfect. As is C, funnily
enough.)
Only a couple of times have links been given (after creating them to make it
possible) when people have accused me of making things up! But I'm not selling
anything.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 31/07/2016 19:58, Terry Reedy wrote:
On 7/31/2016 6:18 AM, BartC wrote:
repeat N:
The benefit is not so much performance, but being able to express
something very easily and quickly.
The cost of the 'repeat' contraction is that one cannot use the loop
variable, either as
ike a bicycle can be in city traffic. It's small, manageable,
understandable, and can go anywhere.
And it can be very nippy. (Very nippy indeed. If I say how long it takes
me to build my compiler from scratch - for my C replacement language -
no one would believe me.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 02/08/2016 15:58, Chris Angelico wrote:
On Tue, Aug 2, 2016 at 9:05 PM, BartC wrote:
I think the real reason is not willing to admit that the language lacks
something that could actually be useful, and especially not to an upstart on
usenet who is not even an expert in that language.
I
On 02/08/2016 18:57, Steven D'Aprano wrote:
On Wed, 3 Aug 2016 03:12 am, BartC wrote:
That's not a fundamental language feature. Repeat-N is. And if properly
designed, isn't an extra feature at all but a special case of a generic
loop.
Which means it is NOT a fundamental l
On 02/08/2016 18:54, Steven D'Aprano wrote:
On Wed, 3 Aug 2016 02:56 am, BartC wrote:
(And I expect that next they will eliminate languages altogether. All
you need is some way of specifying a sequence of calls to library
functions and sprinkling around some control statements;
That wou
On 02/08/2016 22:27, Terry Reedy wrote:
On 8/2/2016 7:05 AM, BartC wrote:
Your objection to a feature such as 'repeat N' doesn't really stack up.
My objection is that there is a real cost that MUST be stacked up
against the benefit.
...
Anyway, if that was a valid obje
guages, but 'str.encode(...)' for example will not.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
ly did one thing but it
did it incredibly well.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
. But sometimes you try to find a .py import module and it doesn't
seem to exist anywhere. (sys.py for example).
I would like to see how such references are translated to Lisp.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
On 03/08/2016 14:31, Chris Angelico wrote:
On Wed, Aug 3, 2016 at 11:23 PM, BartC wrote:
On 03/08/2016 09:58, Steven D'Aprano wrote:
Python is sometimes described as a Lisp with more sensible syntax, so its
not
surprising that it is relatively simple to translate Python to Lisp and
On 03/08/2016 21:12, Chris Angelico wrote:
On Thu, Aug 4, 2016 at 4:52 AM, BartC wrote:
On 03/08/2016 14:31, Chris Angelico wrote:
On Wed, Aug 3, 2016 at 11:23 PM, BartC wrote:
On 03/08/2016 09:58, Steven D'Aprano wrote:
But sometimes you try to find a .py import module and it do
On 03/08/2016 22:39, Chris Angelico wrote:
On Thu, Aug 4, 2016 at 6:53 AM, BartC wrote:
On 03/08/2016 21:12, Chris Angelico wrote:
Fairly common approach - and it means you'll never find those .py
files. So it's no different from looking for sys.py and not finding
it, except that i
501 - 600 of 1116 matches
Mail list logo
