Sorry to hear that. I'm afraid then you'd need to invest more time to go along
this avenue. I know that Inline::Python hasn't nearly gotten the TLC that
Inline::Perl5 has had by Stefan Seifert. And that Inline::Python basically
needs an additional maintainer.
> On 9 Sep 20
Good enough reason to try! I got the 2022.07 release from brew. Then zef
install -v Inline::Python --exclude=python3 (the same incantation I used
before) failed with:
===> Searching for: Inline::Python
===> Found: Inline::Python:ver<0.5>:auth [via
Zef::Repository::LocalCache]
=
mention, this is on a somewhat old version of Raku, 2021.04. But
> then, Inline::Python seems to be mostly even older.
>
>
> On Fri, Sep 9, 2022 at 11:35 AM Elizabeth Mattijsen wrote:
> To rule out any REPL artefacts, do you see the same thing if you put the code
> in a script a
I still see the same behavior. That is, if I do say spark.sql('select
1+1'); twice, the first time prints an empty array, and the second produces
the "instance has no attribute 'sql'" error message.
I forgot to mention, this is on a somewhat old version of Raku, 202
ore fun to work in Raku instead of Python, and I recalled
> that it's supposed to be possible to get handles to Python objects from Raku
> and call methods on them seamlessly, so I tried to make it happen. I got
> pretty far, but now I'm stymied. Here are the steps I can take i
Hello--
I recently started playing around with PySpark. It soon occurred to me
that it would be a lot more fun to work in Raku instead of Python, and I
recalled that it's supposed to be possible to get handles to Python objects
from Raku and call methods on them seamlessly, so I tried to ma
Something like this should do what you want:
timo@schmand ~> perl6 -e 'my $a = gather for ^5 { say "get from a!";
take $_ }; my $b = gather for ^5 { say "get from b!"; take 10 * $_ + 1
}; .say for (|$a, |$b)'
get from a!
0
get from a!
1
get from a!
2
get from a!
3
get from a!
4
get from b!
1
get f
Hello.
I mean, I need a way to concat lazy lists into a lazy list.
Thanks.
--
Hiroki Horiuchi from Japan
The pair constructor seems to be in a different category than the other
quoting operators since the expression that it quotes must look like an
identifier:
https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp#L1776
token fatarrow {
\h* '=>' <.ws>
}
Brian
On Satu
You cannot currently define your own quote-like operators. That will come
with true macros (though you could certainly do it via a slang...
everything is possible with a slang). But they are operators. Not only are
they operators, but they nest other operators. vis:
say "These are my args: {@*ARGS
Quotes are almost a circumfix operator, but they act a bit more like a
macro by controlling the parsing of the contents. But you can do some weird
things like define your own quote-likes.
perl6 -e ' sub circumfix:<>($v) { "{$v}" } ; say B"foo"B ' #
output: foo
or more verbosely
perl6 -e ' sub ci
Wait, quotes *are an operator* ? If so how would I define them? If the
operator returns string, what is the type of its argument? If so that's
even stranger -- most languages they're a hard coded bit of syntax -- the
closest thing I can think of is in C++11 you can add your own string
literal types
>
> it is combining too many new things at once:
Well, it is meant to be the up-front example of everything at once before
the step-by-step...
> * BUILD
> * new
These are the heart of construction. I don't think there's any avoiding
that in a class tutorial.
* submethod
> * bless
These are
people give up. Every
object-oriented language I've used has one constructor-like method that you
define. That Perl6 has two is really strange and unusual (at least coming
from the background of somebody who has "only" been exposed to
C++/Java/Python/Lisp/Haskell). Strange and unusua
been
> hard at work improving the documentation, so if you can point to what's
> missing or unclear, I'm sure it will help a lot.
>>
>>
>> * It would be nice for people coming from Python for a tutorial that
>> explained the basic module importing, the
On Thu, Sep 8, 2016 at 6:41 AM, Kamil Kułaga wrote:
> In perl6 default way is to not write new, BUILD or BUILDALL and also
> not to write accessors. When you create object you can provide
> attributes to initialize, default accessors are generated if field is
> declared with $. sigil.
>
Right, t
On Thu, Sep 8, 2016 at 4:00 AM, Joseph Garvin wrote:
> * I can find no concise easy-to-understand explanation for how to define
> what other languages would call constructors. Instead there is a mess of
> bless, magic inside Mu, new, BUILD, BUILDALL... It's not clear when you
> should prefer to ov
uage/classtut. To
me, it explains the hows and whys very thoroughly. Now, I now people
have been hard at work improving the documentation, so if you can point
to what's missing or unclear, I'm sure it will help a lot.
* It would be nice for people coming from Python for a tutori
ion because they discuss semantics
from an older version of Perl6.
* It would be nice for people coming from Python for a tutorial that
explained the basic module importing, the scope of things imported, and how
name collisions are avoided when importing from two modules that have the
same sub. T
Hi,
On 07/13/2016 11:01 AM, The Holy Ghost wrote:
On linux 2016.04 and windows 2016.01 :
==> Fetching Inline::Python
==> Building Inline::Python
gcc pyhelper.c -Wall -I"/usr/include/python2.7" -L"/usr/lib/python2.7/config"
-lpython2.7 -shared -o /home/erana/.panda-w
On linux 2016.04 and windows 2016.01 :
==> Fetching Inline::Python
==> Building Inline::Python
gcc pyhelper.c -Wall -I"/usr/include/python2.7" -L"/usr/lib/python2.7/config"
-lpython2.7 -shared -o
/home/erana/.panda-work/1468400277_1/resources/libraries/libpyhelper.s
On Mon, May 18, 2015 at 7:46 AM, Tobias Leich wrote:
> We precompile modules using a command line option like in: 'perl6
> --target=mbc --output=foo.pm.moarvm'.
...
> We are working on creating executables such as 'foo.exe' from a given
> Perl 6 script, though I expect that this takes a few months
On Mon, May 18, 2015 at 7:47 AM, Elizabeth Mattijsen wrote:
>> On 18 May 2015, at 14:28, Tom Browder wrote:
...
>> Can anyone point me to more info or say yes or no to possible support of a
>> save-compilation feature?
...
[good answer to my question...]
Thanks Liz and Tobias!
Cheers!
-Tom
> On 18 May 2015, at 14:28, Tom Browder wrote:
>
> I found some discussion of such a capability on the Perl Mongers' site but
> haven't found anything official yet in the Synopses.
>
> But I did find there an option that might do something related:
> --output-format (which is implementation d
We precompile modules using a command line option like in: 'perl6
--target=mbc --output=foo.pm.moarvm'.
Though, since this is for modules, only this incantation will work:
'perl6 -I. -Mfoo -e1'
We are working on creating executables such as 'foo.exe' from a given
Perl 6 script, though I expect tha
I found some discussion of such a capability on the Perl Mongers' site but
haven't found anything official yet in the Synopses.
But I did find there an option that might do something related:
--output-format (which is implementation defined). However, I do not see
that option in Rakudo Perl 6.
C
Fixed in r17210.
e entries for "Get python bytecode translator done"
and "Pass the pie-thon test suite". Are these still active
waypoints on the roadmap, or should we remove them?
Pm
Leopold Toetsch wrote:
I don't know if this was cc'ed to p2p, so just in case.
leo
Subject:
Re: [pirate] Re: languages/python - any plans?
From:
"Tyler Coumbes" <[EMAIL PROTECTED]>
If anyone i
I don't know if this was cc'ed to p2p, so just in case.
leo
--- Begin Message ---
Leo,
We have PMCs in the pirate repo at the moment. They are based off of
the python pmcs in parrot's repo, but work with recent versions of
parrot. Not all features are enabled at the moment, but
Here's a patch which simply remove this function.
No new tests fail, either in parrot or tcl.
Going once...
On Tue Aug 22 17:40:27 2006, chip wrote:
> Hard-coded language names in Parrot are ... well ... bad.
> Very bad.
40217.patch
Description: Binary data
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40217]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40217 >
Hard-coded language names in Parrot are ... well ... bad.
Very bad.
--
Chip Salzenbe
Hello all,
I just thought I would let everyone know I am working on getting the PMCs in
languages/python to compile with the current parrot release(0.4.3). If you
are interested I will be posting to Pirate's mailing list over at
http://pirate.tangentcode.com/
Great work all of you,
Tyler Coumbes
ut below.
~jerry
# Failed test (bc\t\function.t at line 87)
bc\t\functionNOK 6# got: ''python' is not recognized as an internal
or external command,
# operable program or batch file.
# Error reading source file languages/bc\t\function_6_antlr2_no_past.pir.
# &
> I have translated this to:
>
> .namespace ["Foo"]
> .sub g
> .param pmc self
>
> Therefore all the static / default / common "methods" inside Python code
> would be callable with the plain Parrot method call syntax.
>
> The classname contributes
On Wed, 24 Aug 2005, Sam Ruby wrote:
[huge cut]
> Below is from the sample that Leo provided.
>
> > # print foo.f(2)
> >
> > # emulate python find_name, which checks attributes too
> > push_eh m_nf
> > $P0 = foo."f"
inner" Parrot_find_method_with_cache just caches the method
for
a specific class (obeying C3 method resolution order as in Python).
There is no curried function at that stage.
Where does Parrot_find_method_with_cache get this data?
Remember, in Python, there are no methods, there are only properties.
Ab
hod_with_cache just caches the method for
> a specific class (obeying C3 method resolution order as in Python).
> There is no curried function at that stage.
Where does Parrot_find_method_with_cache get this data?
Remember, in Python, there are no methods, there are only properties.
Of cours
upon which it was invoked.
No the "inner" Parrot_find_method_with_cache just caches the method for
a specific class (obeying C3 method resolution order as in Python).
There is no curried function at that stage.
- use a PIC [1] (which is tied to the opcode) and cache
the fina
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Leopold Toetsch wrote:
>
>>> A stripped down PIR-only, pythonless translation is below.
>
>> (example: classes aren't global in Python),
>
> Yes, of course. The stripped down means essential the absenc
Sam Ruby wrote:
Leopold Toetsch wrote:
A stripped down PIR-only, pythonless translation is below.
(example: classes aren't global in Python),
Yes, of course. The stripped down means essential the absence of any
lexical handlings. But as you say, this doesn't matter for the
it is great and the long term goal.
As soon as we compile and run correctly, I'm all about optimizations.
Good Insight Michal,
Kevin,
Michal Wallace wrote:
> Hey Sam,
>I agree with what you're saying in this
>thread. This is slightly off topic, but
>I wanted to point something
ould be emitted by Pirate
>> to correspond to the above code.
>
> A stripped down PIR-only, pythonless translation is below.
Thanks for doing this. Keeping the conversation anchored with code is
very helpful. I have a number of unimportant to the topic at hand
comments on that code
e way this currently works with Pirate and the existing Py*.pmc
closely follows the Python definition, which you can find here:
http://users.rcn.com/python/download/Descriptor.htm#functions-and-methods
Good explanation, thanks.
To illustrate how this works today, lets consider the call to foo.f(2)
me code will need to return
the value of the first parameter.
I'm open to suggestions as to what PIR code should be emitted by Pirate
to correspond to the above code.
The way this currently works with Pirate and the existing Py*.pmc
closely follows the Python definition, which you can fin
On Tue, Aug 23, 2005 at 07:15:41PM -0400, Sam Ruby wrote:
> Leopold Toetsch wrote:
> > I've stated several times that calling conventions need changes to
> > properly support HLLs with minor success at these times.
>
> With the diversity of HLLs out there, I'm not certain that it is wise to
> decl
n through super()).
It might help to anchor this discussion if we focus on a tangible test
case. In particular, lets look at the first few lines of the first
pie-thon test, which can be found here:
http://svn.perl.org/parrot/trunk/languages/python/t/pie/b0.t
What code should be generated f
On Aug 23, 2005, at 22:48, Sam Ruby wrote:
From December 16, 2004:
http://tinyurl.com/8smmq
Sounds like a really ugly misunderstanding, the more that I've proposed
not to pass the object (P2 in old parlance) out of band. I've stated
several times that calling conventions need changes to
On Tue, Aug 23, 2005 at 03:48:03PM -0400, Sam Ruby wrote:
> How will Perl6 evaluate defaults?
I would like to help with this question, but I can't, and in general
p6i won't be the right place to ask. Nobody knows the final form of
Perl 6; nobody knows the currently understood form of Perl 6 excep
Chip Salzenberg wrote:
> I apologize to Leo for accidentally making this reply to the list.
> It was supposed to be private mail, but I hit 'y' just a _little_
> too soon. I had no intention of embarassing anyone. Sorry.
You did, however, cause me to cancel the email I was composing. If
people
On Tue, Aug 23, 2005 at 03:48:03PM -0400, Sam Ruby wrote:
: How will Perl6 evaluate defaults?
:
: Like Python:
:
: global x
: x=1
: def f(p1=x):
: return p1
: x=2
: print f()
:
: or like Ruby:
:
: $x=1
: def f(p1=$x)
: return p1
: end
: $x=2
: puts f()
By default
I apologize to Leo for accidentally making this reply to the list.
It was supposed to be private mail, but I hit 'y' just a _little_
too soon. I had no intention of embarassing anyone. Sorry.
On Tue, Aug 23, 2005 at 01:04:58PM -0700, Chip Salzenberg wrote:
> On Tue, Aug 23, 2005 at 09:58:21PM +0
On Tue, Aug 23, 2005 at 09:58:21PM +0200, Leopold Toetsch wrote:
> Sam, please follow Parrot dev (or stop spreading FUD) - thanks.
Be gentle, please. Parrot needs language developers. I'm not saying
you're right or wrong. I'm just asking you to be a little more
diplomatic.
--
Chip Salzenberg <
ppropriate, suboptimal and whatever for almost
all HLLs. Now you have a complete opcode subset that returns *new*
destination PMCs. http://xrl.us/g9dp
.pragma n_operators 1
...
$P0 = $P1 + $P2 # return new $P0 PMC
Here is a test I've written for pycomplex:
.pragma n_operators
How will Perl6 evaluate defaults?
Like Python:
global x
x=1
def f(p1=x):
return p1
x=2
print f()
or like Ruby:
$x=1
def f(p1=$x)
return p1
end
$x=2
puts f()
- Sam Ruby
P.S. The former prints "1", the latter, "2".
r.
> Some test fail due to remaining uunimplemented features in
> leo-cxt5(default args), or my lack of understanding.
> But a lot of the tests pass.
Take a look at the following:
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "h
My current work.
Python PMC Patch to leo5-cxt5
ils, but has a tendency to set a new direction every week.
> I say that knowing that Leo follows this list. (Hi Leo!)
>
>I do agree with test-driven development. That is exactly the approach I
>took. I will also state that I learned a lot *ABOUT* *PYTHON* in
>running the pie-thon tes
Leopold Toetsch wrote:
>
>> I do agree with test-driven development. That is exactly the approach I
>> took.
>
> Well, I agree - until I see such tests (pyint_1):
>
> $P2 = $P1.__abs__($P1)
Take a look at the difference between r7254 and r7312.
The tests originally passed without a self a
as the first
argument of a method. Therefore all the old workarounds like:
METHOD PMC* __abs__(Interp* interp, PMC* SELF, PMC* self) {}
aren't needed any more.
Sam's PMC's were also incomplete, they lacked support for a lot of the
__add__ style python methods. This is qui
On Tue, Aug 23, 2005 at 06:35:39PM +0200, Leopold Toetsch wrote:
> On Aug 23, 2005, at 17:09, Kevin Tew wrote:
> >Problem:
> >Python PMC's just don't work in the leo-cxt5 branch which will become
> >head/trunk at some time in the hopefully not to distant future
lly.
>
> I added self on Leo's request. Now it is unneccessary. *shrug*
Parrot's calling conventions having updated, everybody must adjust,
it's not about Pirate. I like to think that this most recent change
in calling convention is an improvement, by and large.
> > Sam
On Aug 23, 2005, at 17:09, Kevin Tew wrote:
Problem:
Python PMC's just don't work in the leo-cxt5 branch which will become
head/trunk at some time in the hopefully not to distant future.
Err, I hope to merge RSN ;-)
I had a conversation a long time ago with Dan, in which he a
Kevin Tew wrote:
> Problem:
> Python PMC's just don't work in the leo-cxt5 branch which will become
> head/trunk at some time in the hopefully not to distant future.
>
> What I've done up time now:
> I've ported pyint.pmc, pystring.pmc to pass all tests i
Problem:
Python PMC's just don't work in the leo-cxt5 branch which will become
head/trunk at some time in the hopefully not to distant future.
What I've done up time now:
I've ported pyint.pmc, pystring.pmc to pass all tests in leo-cxt5
I've written t/dynclasses/pystr
# New Ticket Created by Michal Wallace
# Please include the string: [perl #36525]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36525 >
This is a simple patch to get pyboolean.pmc
working in the pirate test suite again.
dynclasses/py*.pmc need some work. At the time Sam Ruby created these
PMCs, Parrot didn't provide all the semantics necessary to support
Python. This situation is by far better now but the transition of Parrot
internals isn't yet finished.
Anyway, the following issues are existing
I just set up a new list for pirate, a python
compiler for parrot.
Quite a bit of work has been done on pirate since I
last updated the website back in 2003, mostly by
Sam Ruby of http://intertwingly.net/
Sam is giving a python-on-parrot presentation at
OSCON on August 4, so I'd li
On Wed, 25 May 2005, [EMAIL PROTECTED] wrote:
hi
python on parrot already have not develop?
Hi there,
I'm not sure I understand your question either...
But maybe this will help?
http://pirate.tangentcode.com/
- Michal
http://withoutane.com/
On Wed, May 25, 2005 at 01:29:51PM +0800, [EMAIL PROTECTED] wrote:
> hi
>
> python on parrot already have not develop?
That question doesn't make sense as is - I think it lost something in
translation. By "develop" did you mean "developers" (human
hi
python on parrot already have not develop?
bloves
[EMAIL PROTECTED]
2005-05-25
Especially goals below ...
leo
Original Message
Subject: [Python-Dev] First PyPy (preview) release
Date: Fri, 20 May 2005 23:44:29 +0200
From: Armin Rigo <[EMAIL PROTECTED]>
To: python-dev@python.org
The PyPy 0.6 release
*The PyPy Development T
ted his post
as a spike of how a pirate refactoring could go, not a call
to start a whole new incompatible project.
And am working to generate a python to pir
translator/compiler that uses Sam's python pmc's I've
attached the source as it stands now. I'm just an
aspiring parrot
Re: Pyrate( Sam's stub code )
I've taken the code from
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip, which I
assume to be Sam's code.
It was basically stubs with a few AST nodes implemented when I started
with it.
And am working to generate a python to pir translato
wrote:
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
I haven't looked at it for a few months now. I do plan to revisit
it enough to g
wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
I haven't looked at it for a few months now. I do plan to revisit it
enough to get the Pie-thon tes
ng
MMD system I'v also changed Python (and Tcl) PMCs accordingly. E.g.
subtracting two PyInts gives a PyLong on overflow albeit the subtract is
inherited from the Integeer PMC.
See also:
Subject: [PROPOSAL] infix MMD operators
Subject: Again the infix ops
That's not yet finished
[I hope you don't mind me putting this back on the list - I would prefer
that everybody who is interested can follow along and/or participate]
Kevin Tew wrote:
Sam Ruby wrote:
Kevin Tew wrote:
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
Kevin Tew wrote:
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
I haven't looked at it for a few months now. I do plan to revis
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
Is there a up to date cvs repo?
Can we get this code checked into the parrot svn repo?
Kevin
ring, as Activestate's build of 2.4.0 reports it as
C:\>python -V
Python 2.4
The patch makes the patchlevel optional, which will be reported as 0
if not found.
Ron
python_version_check.patch
Description: Binary data
A. Pagaltzis writes:
> Hi all,
>
> so Guido is talking about his reasoning behind dropping lambda,
> reduce(), filter() and map() in the next generation of Python:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
>
> [Prime quote: "I think having the
> "AP" == A Pagaltzis <[EMAIL PROTECTED]> writes:
AP> [Prime quote: "I think having the two choices side-by-side just
AP> requires programmers to think about making a choice that's
AP> irrelevant for their program; not having the choice streamlines
AP> the thought process."]
it just p
A. Pagaltzis skribis 2005-03-13 23:40 (+0100):
> [Prime quote: "I think having the two choices side-by-side just
> requires programmers to think about making a choice that's
> irrelevant for their program; not having the choice streamlines
> the thought process."]
> But, philosophical point of view
Hi all,
so Guido is talking about his reasoning behind dropping lambda,
reduce(), filter() and map() in the next generation of Python:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
[Prime quote: "I think having the two choices side-by-side just
requires programmers to think
Will Coleda via RT wrote:
Sam's latest patch seems to have resolved this issue - dynclasses now build,
and:
perl t/harness t/dynclass/py*
skips 1 test, passes everything else.
What test is skipped?
[EMAIL PROTECTED]:~/parrot/dynclasses$ make test
cd .. ; perl -Ilib t/harness t/dynclass/*.t
t/dyncl
# New Ticket Created by Will Coleda
# Please include the string: [perl #33036]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33036 >
Fresh cvs update, make realclean, configure, make:
c++ -L/usr/local/lib -flat_namesp
Sam's latest patch seems to have resolved this issue - dynclasses now build,
and:
perl t/harness t/dynclass/py*
skips 1 test, passes everything else.
Thanks.
27;ve posted a graphic of all these possibilities in one of the mails.
This is the reason why I'm prefering to replace all with just one
scheme that works, i.e. doing full dynamic dispatch at the opcode level.
> People writing Python to Parrot translators need to know Parrot
> inte
_method class 'A' method '__absolute': Sub
# Calling sub '__absolute'
...
But only for classes that inherit from delegate.
If Perl programmers need to know about Parrot method names, then
effectively this beomes part of the Perl language specification. I do
not have th
# find_method class 'A' method '__absolute': Sub
# Calling sub '__absolute'
...
> ... Nor does the lookup involved in find_method_p_p_s for that
> matter.
???
> If Perl programmers need to know about Parrot method names, then
> effectively this beomes part of th
se of
find_method. Nor does the lookup involved in find_method_p_p_s for that
matter.
If Perl programmers need to know about Parrot method names, then
effectively this beomes part of the Perl language specification. I do
not have the luxury of changing the Python language specificatio
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Sam Ruby <[EMAIL PROTECTED]> wrote:
>>
>> [ snipped - all ok }
>>
>>>If I define an __add__ method with 16 arguments, Python will not throw
>>>an exception.
>>
>>
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
[ snipped - all ok }
If I define an __add__ method with 16 arguments, Python will not throw
an exception.
I didn't write that. I've said: *if* you call it via "a + b", Python
throws an exception - that one I
Sam Ruby <[EMAIL PROTECTED]> wrote:
[ snipped - all ok }
> If I define an __add__ method with 16 arguments, Python will not throw
> an exception.
I didn't write that. I've said: *if* you call it via "a + b", Python
throws an exception - that one I've s
not provided
> such behavior, then an any __add__ method provided needs to be
> called.
Ok. But that would imply that HLL interoperbility isn't really possible. Or
just at a minimal surface level. But see below.
I don't believe that to be the case. If a Perl subroutine were to call
This is the critical part of it. The "__dict__" of your class provides the
namespace. Setting a key in that namespace (or an attribute of your class
with that key) has a special meaning in Python, *if* that key happens to
be one of the method names.
While the Python people aren
On 2004-12-03 at 14:46:16, John Siracusa wrote:
> Anyway, I thought it was interesting to see the ease of "forward
> compatibility" for simple attributes touted as a feature of Python. I'd
> like to tout it as a feature of Perl 6 too, because I also hate writing
> gett
On Fri, Dec 03, 2004 at 02:05:16PM -0500, John Siracusa wrote:
> >From http://dirtsimple.org/2004/12/python-is-not-java.html
>
> "In Java, you have to use getters and setters because using public fields
> gives you no opportunity to go back and change your mind later to
John Siracusa writes:
> I guess I wasn't asking if it would be "possible" (I think that's been
> established), but if it would be "easy", "reasonable", or "clean" (as
> it appears to be in Python, although I'm just going by what t
1 - 100 of 273 matches
Mail list logo