alex23 wrote:
> On Nov 24, 5:47 pm, Dokorek <[EMAIL PROTECTED]> wrote:
>> Python 3000 (a.k.a. "Py3k", and released as Python 3.0) is a new
>> version of the language that is incompatible with the 2.x line of
>> releases. The language is mostly the same, but many details,
>> especially how built-in
On Nov 24, 5:47 pm, Dokorek <[EMAIL PROTECTED]> wrote:
> Python 3000 (a.k.a. "Py3k", and released as Python 3.0) is a new
> version of the language that is incompatible with the 2.x line of
> releases. The language is mostly the same, but many details,
> especially how built-in objects like diction
rahul wrote:
> I am trying to find out what Python C APIs are changing from Python
> 2.5 to Python 3.0 but there does not seem to be a single list of
> changes (or at least google is not finding one).
> If someone knows about where I should look, please let me know.
Check out what Cython does in i
On Aug 23, 10:34 am, rahul <[EMAIL PROTECTED]> wrote:
> I am trying to find out what Python C APIs are changing from Python
> 2.5 to Python 3.0 but there does not seem to be a single list of
> changes (or at least google is not finding one).
> If someone knows about where I should look, please let
On Sat, Aug 23, 2008 at 11:34 AM, rahul <[EMAIL PROTECTED]> wrote:
> I am trying to find out what Python C APIs are changing from Python
> 2.5 to Python 3.0 but there does not seem to be a single list of
> changes (or at least google is not finding one).
> If someone knows about where I should loo
On Jun 24, 5:11 pm, [EMAIL PROTECTED] wrote:
> Well chosen restrictions sometimes are very useful, they may act like
> a scaffolding, you can build higher constructions on them (Python has
> no macros, this is a restriction. But this restriction has some
> advantages. One of the main advantages is
Flaming Thunder FTW!!!
thank you, I'm here all week.
--
http://mail.python.org/mailman/listinfo/python-list
On 24 Jun., 13:19, [EMAIL PROTECTED] wrote:
> If you want to see an advanced language, you may take a look at
> PyMeta, that's a bit of the future of the computer
> science:http://washort.twistedmatrix.com/
Er, no. The future of CS is also its past i.e. EBNF ;)
--
http://mail.python.org/mailman
On 24 Jun., 13:19, [EMAIL PROTECTED] wrote:
> If you want to see an advanced language, you may take a look at
> PyMeta, that's a bit of the future of the computer
> science:http://washort.twistedmatrix.com/
Er, no. The future of CS is also its past i.e. EBNF ;)
--
http://mail.python.org/mailman
Michele Simionato:
Also consider the famous Clinger's maxim
> “Programming languages should be designed not by piling feature
> on top of feature, but by removing the weaknesses and restrictions
> that make additional features appear necessary.”
I'm relaxed, don't worry :-)
I know that maxim, but
On Jun 24, 1:19 pm, [EMAIL PROTECTED] wrote:
> Michele Simionato:
>
> > It is worth reminding that, in more than one sense, the most advanced
> > language is the one with less features ...
>
> I don't agree, Scheme or Brainfuck may have less features, but this
> doesn't make them more advanced, it
In article <[EMAIL PROTECTED]>,
Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> The fact that
> it still hasn't been released after 8 years of development (Larry
> announced it in his State of the Onion speech in 2000 I think) makes
> me think that I made the right choice.
Sometimes you gotta be pa
Corey G. <[EMAIL PROTECTED]> wrote:
> The main concern (my concern) is whether or not Perl 6 is
> more like Java with pre-compiled byte code (did I say that right)
See below for some python VM comments
> and whether or not individuals without the ability to see past the
> surface will begin
[EMAIL PROTECTED]:
> I believe Python 3k will (when out of beta) will have a speed
> similar to what it has currently in 2.5, possibly with speed ups
> in some locations.
Python 3 uses by default unicode strings and multiprecision integers,
so a little slowdown is possible.
Michele Simionato:
>
On Jun 24, 11:16 am, [EMAIL PROTECTED] wrote:
> Towards it being more advanced than Python 3k, time will tell.
It is worth reminding that, in more than one sense, the most advanced
language is the one with less features ...
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 24, 10:36 am, "Corey G." <[EMAIL PROTECTED]> wrote:
> What I meant, in terms of dealing with accurate or non-accurate rumors
> is with speed, yes. There are plenty of comparisons where Perl is
> 4-15x faster then Python for 'some' operations regarding regular
> expressions, etc.
>
> For me
What I meant, in terms of dealing with accurate or non-accurate rumors
is with speed, yes. There are plenty of comparisons where Perl is
4-15x faster then Python for 'some' operations regarding regular
expressions, etc.
For me personally, this means absolutely nothing because if I spend
On Jun 24, 8:20 am, "Corey G." <[EMAIL PROTECTED]> wrote:
> If Perl 6 ever does get on its feet and get released, how does it
> compare to Python 3000? Is Perl 6 more like Java now with Parrot? I
> just want to make sure that Python is staying competitive.
>
> If this is the wrong mailing list, j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 19, 2008, at 4:43 AM, Paul Moore wrote:
On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team and the Python community,
I am
happy to announce the fir
On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I am
> happy to announce the first beta releases of Python 2.6 and Python 3.0.
Any ETA for Windows builds? The web pages s
[EMAIL PROTECTED] wrote:
> As a new comer to Python I was wondering which is the best to start
> learning. I've read that a number of significant features have
> changed between the two versions. Yet, the majority of Python
> programs out in the world are 2.x and it would be nice to understand
>
On Jun 13, 5:04 pm, [EMAIL PROTECTED] wrote:
> As a new comer to Python I was wondering which is the best to start
> learning. I've read that a number of significant features have
> changed between the two versions. Yet, the majority of Python
> programs out in the world are 2.x and it would be
[EMAIL PROTECTED] wrote:
> As a new comer to Python I was wondering which is the best to start
> learning. I've read that a number of significant features have
> changed between the two versions. Yet, the majority of Python
> programs out in the world are 2.x and it would be nice to understand
>
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| As a new comer to Python I was wondering which is the best to start
| learning. I've read that a number of significant features have
| changed between the two versions. Yet, the majority of Python
| programs out in the world are 2.x
On Jun 13, 4:13 pm, Mensanator <[EMAIL PROTECTED]> wrote:
> On Jun 13, 4:04 pm, [EMAIL PROTECTED] wrote:
>
> > As a new comer to Python I was wondering which is the best to start
> > learning. I've read that a number of significant features have
> > changed between the two versions. Yet, the majo
On Jun 13, 4:04 pm, [EMAIL PROTECTED] wrote:
> As a new comer to Python I was wondering which is the best to start
> learning. I've read that a number of significant features have
> changed between the two versions. Yet, the majority of Python
> programs out in the world are 2.x and it would be n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 1, 2008, at 5:26 PM, Martin v. Löwis wrote:
>> As of 4:50 PM EST, the links to Windows installers give 404 File Not
>> Found.
>>
>> I gather that they are still in process,
>> and notice that there is no public c.l.p. announcement.
>
> I just
> As of 4:50 PM EST, the links to Windows installers give 404 File Not
> Found.
>
> I gather that they are still in process,
> and notice that there is no public c.l.p. announcement.
I just fixed that. The files were there; just the links were wrong.
Regards,
Martin
--
http://mail.python.org
On Jan 19, 7:54 pm, Brad <[EMAIL PROTECTED]> wrote:
> Just playing around with Python3000 a2 release on Windows XP 32-bit x86.
>
> import __hello__
>
> doesn't print 'hello world...' as it does on 2.5
Thanks for spoiling this easter egg for me!
;)
--
http://mail.python.org/mailman/listinfo/p
Brad wrote:
> Just playing around with Python3000 a2 release on Windows XP 32-bit x86.
>
> import __hello__
>
> doesn't print 'hello world...' as it does on 2.5
>
> The import doesn't fail or generate errors... just no output. Perhaps
> this is by design?
I changed the __hello__ frozen module
2007/12/9, hashcollision <[EMAIL PROTECTED]>:
> From http://ivory.idyll.org/blog/dec-07/conversions.html:
> class X:
> internal = [5,6,7,8]
> def __getitem__(self, i):
> return self.internal[i]
>
> x = X()
>
> l = [1,2,3]
> print l + x
>
>
>
> fails withTypeError: can only concatenate list (not
Tim Golden wrote this on Mon, 04 Jun 2007 15:55:30 +0100. My reply is
below.
> Chuck Rhode wrote:
>> samwyse wrote this on Mon, 04 Jun 2007 12:02:03 +. My reply is
>> below.
>>> I think it would be a good thing if a standardized interface
>>> existed, similar to PEP 247. This would make i
Chuck Rhode wrote:
> samwyse wrote this on Mon, 04 Jun 2007 12:02:03 +. My reply is
> below.
>
>> I think it would be a good thing if a standardized interface
>> existed, similar to PEP 247. This would make it easier for one
>> script to access multiple types of archives, such as RAR, 7-Zip,
samwyse wrote this on Mon, 04 Jun 2007 12:02:03 +. My reply is
below.
> I think it would be a good thing if a standardized interface
> existed, similar to PEP 247. This would make it easier for one
> script to access multiple types of archives, such as RAR, 7-Zip,
> ISO, etc.
Gee, it would
Steve Holden <[EMAIL PROTECTED]> wrote:
>> As a matter of interest do PyLint or PyChecker check for this situation
>> (chained assignment where the target of an assignment is also a
>> subexpression of a later assignment)?
>>
> Where's the published syntax for chained assignment?
http://docs.p
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > The assignment order is specified in the language reference.
|
| Where? I'm looking at
|
| http://docs.python.org/ref/assignment.html
|
| right now.
The first line of the syntax grammar is:
assi
Actually, after studying this a bit more:
http://docs.python.org/ref/assignment.html
I guess that makes sense. Sorry if I muddied the water for anyone else in my
boat:
n1 = n1.next = n2
The first thing that happens is the expression list is evaluated which is
the thing on the far right, n2. That
"Virgil Dupras" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > class Node:
> > > ... pass
> > > ...
> > node = Node()
> > nextnode = Node()
> > backup_node = node
> > node = node.next = nextnode
> > node.next is node
> > > True
> > hasattr(ba
Mark T wrote:
>
> "Alex Martelli" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> John Nagle <[EMAIL PROTECTED]> wrote:
>>
>>> Marcin Ciura wrote:
>>>
>>> > Neither would I. I must have expressed myself not clearly enough.
>>> > Currently
>>> > x = y = z
>>> > is roughly equiv
John Nagle wrote:
>
> That's fascinating. Is that a documented feature of the language,
> or a quirk of the CPython interpreter?
>
Its a documented feature of the language. From the Reference Manual:
"An assignment statement evaluates the expression list (remember that
this can be a single ex
Steve Holden <[EMAIL PROTECTED]> wrote:
> In other words,
>
> assignment_stmt ::= (target_list "=") expression_list |
> (target_list "=") assignment_stmt
>
> and
>
> assignment_stmt ::= (target_list "=") assignment_stmt |
>
Duncan Booth wrote:
> Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>> As a matter of interest do PyLint or PyChecker check for this situation
>>> (chained assignment where the target of an assignment is also a
>>> subexpression of a later assignment)?
>>>
>> Where's the published syntax for chaine
Duncan Booth wrote:
> Steve Holden <[EMAIL PROTECTED]> wrote:
>
>> Help me out here. It looks as though the real syntax should
>> be something like
>>
>> assignment_stmt ::= (target_list "=")+ expression_list |
>> (target_list "=")+ assignment_stmt
>
Steve Holden <[EMAIL PROTECTED]> wrote:
> Help me out here. It looks as though the real syntax should
> be something like
>
> assignment_stmt ::= (target_list "=")+ expression_list |
> (target_list "=")+ assignment_stmt
That is precisely the point. I
Duncan Booth wrote:
> "Virgil Dupras" <[EMAIL PROTECTED]> wrote:
>
>> I think I see what Marcin means. The 'node' is changed too fast in the
>> chain, and next is assigned to 'nextnode' instead of being assigned to
>> node.
>
> I can see why Marcin was confused. Many other languages assignment is
"Virgil Dupras" <[EMAIL PROTECTED]> wrote:
> I think I see what Marcin means. The 'node' is changed too fast in the
> chain, and next is assigned to 'nextnode' instead of being assigned to
> node.
I can see why Marcin was confused. Many other languages assignment is an
expression, so a=b=c is si
Mark T wrote:
> "Alex Martelli" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> John Nagle <[EMAIL PROTECTED]> wrote:
>>
>>> Marcin Ciura wrote:
>>>
Neither would I. I must have expressed myself not clearly enough.
Currently
x = y = z
is roughly equivalent to
>
Terry Reedy wrote:
> "Mark T" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | This is interesting:
> |
> | >>> class Test(object):
> | ... def __getattribute__(self,n):
> | ... print 'reading',n
> | ... return object.__getattribute__(self,n)
> | ... def __setattr__(se
"Mark T" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| This is interesting:
|
| >>> class Test(object):
| ... def __getattribute__(self,n):
| ... print 'reading',n
| ... return object.__getattribute__(self,n)
| ... def __setattr__(self,n,v):
| ... print 'writing',n
"Alex Martelli" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> John Nagle <[EMAIL PROTECTED]> wrote:
>
>> Marcin Ciura wrote:
>>
>> > Neither would I. I must have expressed myself not clearly enough.
>> > Currently
>> > x = y = z
>> > is roughly equivalent to
>> > x = z
>> > y = z
"Marcin Ciura" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Given
> class Node(object):
> pass
>
> node = Node()
> nextnode = Node()
>
> I tried to refactor the following piece of code
> node.next = nextnode
> node = nextnode
You have an error above. The first n
Virgil Dupras wrote:
> On Mar 21, 9:24 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Marcin Ciura wrote:
>>> Steven D'Aprano wrote:
>>> x, y, z = 1, 2, 3
>>> x = y = z
>>> x, y, z
(3, 3, 3)
I certainly wouldn't expect to get (2, 3, 3).
>>> Neither would I. I must have express
On Mar 21, 10:05 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> Virgil Dupras wrote:
> > On Mar 21, 9:24 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> >> Marcin Ciura wrote:
> >>> Steven D'Aprano wrote:
> >>> x, y, z = 1, 2, 3
> >>> x = y = z
> >>> x, y, z
> (3, 3, 3)
> I certa
John Nagle <[EMAIL PROTECTED]> wrote:
> Marcin Ciura wrote:
>
> > Neither would I. I must have expressed myself not clearly enough.
> > Currently
> > x = y = z
> > is roughly equivalent to
> > x = z
> > y = z
> > I propose to change it to
> > y = z
> > x = z
>
> Actually, it is equivalent to
>
On Mar 21, 9:24 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> Marcin Ciura wrote:
> > Steven D'Aprano wrote:
> > x, y, z = 1, 2, 3
> > x = y = z
> > x, y, z
> >> (3, 3, 3)
>
> >> I certainly wouldn't expect to get (2, 3, 3).
>
> > Neither would I. I must have expressed myself not clearl
Marcin Ciura wrote:
> Steven D'Aprano wrote:
> x, y, z = 1, 2, 3
> x = y = z
> x, y, z
>> (3, 3, 3)
>>
>> I certainly wouldn't expect to get (2, 3, 3).
>
> Neither would I. I must have expressed myself not clearly enough.
> Currently
> x = y = z
> is roughly equivalent to
> x = z
> y =
Marcin Ciura wrote:
> Neither would I. I must have expressed myself not clearly enough.
> Currently
> x = y = z
> is roughly equivalent to
> x = z
> y = z
> I propose to change it to
> y = z
> x = z
Actually, it is equivalent to
y = z
x = y
> Python performs chained assignments
"Marcin Ciura" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Neither would I. I must have expressed myself not clearly enough.
| Currently
| x = y = z
| is roughly equivalent to
| x = z
| y = z
except that z is only evaluated once.
| I propose to change it to
| y = z
| x = z
Un
Steven D'Aprano wrote:
x, y, z = 1, 2, 3
x = y = z
x, y, z
>
> (3, 3, 3)
>
> I certainly wouldn't expect to get (2, 3, 3).
Neither would I. I must have expressed myself not clearly enough.
Currently
x = y = z
is roughly equivalent to
x = z
y = z
I propose to change it to
y = z
x = z
On Wed, 21 Mar 2007 22:53:55 +0100, Marcin Ciura wrote:
> Given
>class Node(object):
>pass
>
>node = Node()
>nextnode = Node()
>
> I tried to refactor the following piece of code
>node.next = nextnode
>node = nextnode
>
> as
>node = node.next = nextnode
>
> only
Marcin Ciura <[EMAIL PROTECTED]> writes:
>node = node.next = nextnode
>
> only to discover that Python performs chained assignments
> backwards compared to other languages, i.e. left-to-right
> instead of right-to-left.
What makes you think so?
>>> a = "foo"
>>> b = "bar"
>>> c =
George Sakkis wrote:
> Carl Banks wrote:
> > George Sakkis wrote:
> > > If by 'respond to "+"' is implied that you can get a "TypeError:
> > > iterable argument required", as you get now for attempting "x in y" for
> > > non-iterable y, why not ?
> >
> > Bad idea on many, many levels. Don't go th
Carl Banks wrote:
> Georg Brandl wrote:
>> What has a better chance of success in my eyes is an extension to yield
>> all items from an iterable without using an explicit for loop: instead of
>>
>> for item in iterable:
>> yield item
>>
>> you could write
>>
>> yield from iterable
>>
>> or
>>
Carl Banks wrote:
> George Sakkis wrote:
> > Fredrik Lundh wrote:
> >
> > > George Sakkis wrote:
> > >
> > > > The base object class would be one candidate, similarly to the way
> > > > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> > > >
> > > > Alternatively, iter() co
George Sakkis wrote:
> Fredrik Lundh wrote:
>
> > George Sakkis wrote:
> >
> > > The base object class would be one candidate, similarly to the way
> > > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> > >
> > > Alternatively, iter() could be a wrapper type (or perhaps mix
Georg Brandl wrote:
> What has a better chance of success in my eyes is an extension to yield
> all items from an iterable without using an explicit for loop: instead of
>
> for item in iterable:
> yield item
>
> you could write
>
> yield from iterable
>
> or
>
> yield *iterable
Since this is
Fredrik Lundh wrote:
> George Sakkis wrote:
>
> > The base object class would be one candidate, similarly to the way
> > __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
> >
> > Alternatively, iter() could be a wrapper type (or perhaps mixin)
> > instead of a function, somet
George Sakkis wrote:
> Fredrik Lundh wrote:
>
>> John Reese wrote:
>>
>> > It seems like it would be clear and mostly backwards compatible if the
>> > + operator on any iterables created a new iterable that iterated
>> > throught first its left operand and then its right, in the style of
>> > iter
George Sakkis wrote:
> The base object class would be one candidate, similarly to the way
> __nonzero__ is defined to use __len__, or __contains__ to use __iter__.
>
> Alternatively, iter() could be a wrapper type (or perhaps mixin)
> instead of a function, something like:
so you're proposing to
Fredrik Lundh wrote:
> John Reese wrote:
>
> > It seems like it would be clear and mostly backwards compatible if the
> > + operator on any iterables created a new iterable that iterated
> > throught first its left operand and then its right, in the style of
> > itertools.chain.
>
> you do know th
John Reese wrote:
> It seems like it would be clear and mostly backwards compatible if the
> + operator on any iterables created a new iterable that iterated
> throught first its left operand and then its right, in the style of
> itertools.chain.
you do know that "iterable" is an informal interf
Michael> So why not make "x % y" for floats behave exactly like it does
Michael> for integers and provide a separate operation with your
Michael> described behavior?
%% anyone?
(Skip ducks and runs...)
Skip
--
http://mail.python.org/mailman/listinfo/python-list
Tim Peters writes:
> IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> for Python to try to define % the same way for ints and floats.
[...]
> I'd like to see this change in Python 3000. Note that IBM's proposed
> standard for decimal arithmetic (which Python's "dec
Guido van Rossum a écrit :
> This is way above my head. :-)
>
> The only requirement *I* would like to see is that for floats that
> exactly represent ints (or longs for that matter) the result ought of
> x%y ought to have the same value as the same operation on the
> corresponding ints (except if
This is way above my head. :-)
The only requirement *I* would like to see is that for floats that
exactly represent ints (or longs for that matter) the result ought of
x%y ought to have the same value as the same operation on the
corresponding ints (except if the result can't be represented exactl
Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
>> My main point was/is: why is there not more discussion about "true
>> division" !!?
>
> You are about three years too late for the discussion. It was debated to
> death when Guido proposed that Python should behave more like
> non-programmers ex
Steven D'Aprano wrote:
> The tutorial shouldn't talk about Python3000 at all. What would be the
> point of that? The tutorial is there to teach about the way Python works
> now, not to make guesses and prediction about how it will work some time
> in the indefinite future.
There is no guessing inv
Caution: bunny trail ahead. Feel free to skip this message, as it
contains no useful content whatever...
On Sat, 18 Feb 2006 12:09:02 +1100 in comp.lang.python, Steven
D'Aprano <[EMAIL PROTECTED]> wrote:
[...]
>
>I've never even used Matlab. But I have a calculator. (Actually I have
>about half
[EMAIL PROTECTED] wrote:
> Thank you very much, Magnus !
> This is the answer I had been waiting for:
>
>>A problem as I see it today, is that this behaviour is
>>not actively encouraged. The tutorial, which is maintained
>>and updated, still describes old style classes, and the
>>old division beh
Magnus Lycka wrote:
> Gregory Piñero wrote:
> > I knew about that approach. I just wanted less typing :-(
>
> It's enough to introduce one float in the mix.
> 1.*a/b or float(a)/b if you don't want one more
> multiplication.
That doesn't work if either a or b is a Decimal. What *could* work is
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> not actively encouraged. The tutorial, which is maintained
>> and updated, still describes old style classes, and the
>> old division behaviour.
Perhaps the tutorials needs updating.
> My main point was/is: why is there not more di
On Fri, 17 Feb 2006 14:01:05 -0800, seb.haase wrote:
> Thank you very much, Magnus !
> This is the answer I had been waiting for:
>> A problem as I see it today, is that this behaviour is
>> not actively encouraged. The tutorial, which is maintained
>> and updated, still describes old style classe
Thank you very much, Magnus !
This is the answer I had been waiting for:
> A problem as I see it today, is that this behaviour is
> not actively encouraged. The tutorial, which is maintained
> and updated, still describes old style classes, and the
> old division behaviour.
My main point was/is:
[EMAIL PROTECTED] wrote:
> Hi,
> Is it true that that "Python 3000" is dead ?
I think you should view Python 3000 as a metaphor for
"Python as it would look if we didn't have to care about
backward compatibility".
Before this name appeared, Guido used to talk about
Python 3.0 as a version where b
Steven D'Aprano wrote:
> Anybody using Python *should* be aware of the division issue. As soon as
> they see a division, it is their responsibility to *find out what it
> means*. That doesn't require much work: they can scroll up to the
> beginning of the module and look at the first few lines. Th
Gregory Piñero wrote:
> I knew about that approach. I just wanted less typing :-(
It's enough to introduce one float in the mix.
1.*a/b or float(a)/b if you don't want one more
multiplication.
--
http://mail.python.org/mailman/listinfo/python-list
Thanks for the replies,
But to point out what the subject of this thread is (sorry for the typo
;-) :
There is a PEP (proposal 238) to change Python so that
5/2 WOULD do the true division -- and obviously break lots of code.
Just type this in your python interpeter:
>>> from __future__ import
On Thu, 16 Feb 2006 20:55:42 -0800, seb.haase wrote:
> I don't think "Because this change might break code, it's being
> introduced very gradually. Python 2.2 begins the transition, but the
> switch won't be complete until Python 3.0." says enough.
I'm not sure what else should be said.
> Shou
I knew about that approach. I just wanted less typing :-(
On 2/14/06, Rocco Moretti <[EMAIL PROTECTED]> wrote:
> Gregory Piñero wrote:
> > On 14 Feb 2006 06:44:02 -0800, [EMAIL PROTECTED]
> >
> >
> >>5./2.=2.5 is floating point math, with all the round off errors that
> >>incorporates.
> >
> > T
Gregory Piñero wrote:
> On 14 Feb 2006 06:44:02 -0800, [EMAIL PROTECTED]
>
>
>>5./2.=2.5 is floating point math, with all the round off errors that
>>incorporates.
>
> Thanks Curtis, I never knew that trick. I guess for variables do have
> true division you have to make them floats? e.g.
> flo
On 14 Feb 2006 06:44:02 -0800, [EMAIL PROTECTED]
> 5./2.=2.5 is floating point math, with all the round off errors that
> incorporates.
Thanks Curtis, I never knew that trick. I guess for variables do have
true division you have to make them floats? e.g.
float(var1)/float(var2)? Or do you know
[EMAIL PROTECTED] wrote:
> Hi,
> Is it true that that "Python 3000" is dead ?
> Honestly I think that e.g. changing 5/2 to be 2.5 (instead of 2) would
> just break to much code :-(
> On the otherhand I'm using Python as "Matlab replacement" and would
> generally like 5/2 ==2.5
>
>...
It's Comp. S
Nicolas Fleury wrote:
Mirko Zeibig wrote:
This is not an option for e.g. IDEs as some functions might actually
do something when called ;-) and I like `callable` for introspection.
Other ways would be to check for the `__call__` attribute or use
several methods of the `inspect`-Module, both of w
Mirko Zeibig wrote:
This is not an option for e.g. IDEs as some functions might actually do
something when called ;-) and I like `callable` for introspection.
Other ways would be to check for the `__call__` attribute or use several
methods of the `inspect`-Module, both of which are not better th
Raymond Hettinger wrote:
[Steven Bethard] I'm just suggesting that in a function with a
*args in the def, the args variable be an iterator instead of
a tuple.
So people would lose the useful abilities to check len(args) or extract
an argument with args[1]?
No more than you lose these abilities wi
[Steven Bethard] I'm just suggesting that in a function with a
> *args in the def, the args variable be an iterator instead of
> a tuple.
So people would lose the useful abilities to check len(args) or extract
an argument with args[1]?
Besides, if a function really wants an iterator, then its si
Raymond Hettinger wrote:
[Steven Bethard]
What I would prefer is something like:
>>> zip(*g(4))
>>> x, y, z = zip(*g(4))
>>> x, y, z
(, at ...)
2. It is instructive to look at Guido's reactions to other *args
proposals. His receptivity to a,b,*c=it wanes whenever someone then
requests support fo
Raymond Hettinger wrote:
[...]
"Not everything that can be done, should be done."
... and not everything that should be done, can be done.
regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
...
> "Not everything that can be done, should be done."
Or, to quote Scripture...:
"'Everything is permissible for me' -- but not everything is beneficial"
(1 Cor 6:12)...
Alex
--
http://mail.python.org/mailman/listinfo/python-list
[Steven Bethard]
> What I would prefer is something like:
>
> >>> zip(*g(4))
>
> >>> x, y, z = zip(*g(4))
> >>> x, y, z
> (, So I guess my real question is, should I expect Python 3000 to play
> nicely with *args and iterators? Are there reasons (besides
backwards
> incompatibility) that pars
1 - 100 of 116 matches
Mail list logo
