The Artima Developer Community
Sponsored Link

Weblogs Forum
Python 3000 Status Update (Long!)

47 replies on 4 pages. Most recent reply: Jun 13, 2008 4:43 PM by Brad Schick

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 47 replies on 4 pages [ « | 1 2 3 4 | » ]
Chuck Adams

Posts: 3
Nickname: chuckadams
Registered: Feb, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 22, 2007 11:16 AM
Reply to this message Reply
Advertisement
The first item under miscellaneous is confusing: if == compares identity and not value, then it would seem to be very much changed from 2.x. If this is in the context of inequality operators, then it doesn't seem to be worth mentioning in the same sentence, especially if it hasn't actually changed from 2.x

You've got everyone worried they'll have to import the "foo".equals(string) idiom from Java -- I can't imagine anyone seriously advocating for that horrid misfeature!

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Python 3000 Status Update (Long!) Posted: Jun 23, 2007 2:32 PM
Reply to this message Reply
> In your presentation last night you had one slide which
> talked about the "str" vs "bytes" types in Python 3000. On
> the bottom of that slide was something like:
>
> str(b"asdf") == "b'asdf'"
>
> However, in discussing this slide (very briefly) you said
> that a type constructors like "str" could be used to do
> conversion. It seems like "str" is behaving more like
> "repr" in this case, which seems unusual and less useful
> to me. Was this a typo, or is this actually the way it's
> supposed to work? What's the rationale?

To be honest, this is an open issue. The slide was wrong compared to the current implementation; but the implementation currently defaults to utf8 (so str(b'a') == 'a'), which is not right either. The problem is that there are conflicting requirements: str() of any object should ideally always return something, but we don't want str() to assume a specific default encoding.

To be continued...

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Python 3000 Status Update (Long!) Posted: Jun 23, 2007 2:34 PM
Reply to this message Reply
> The first item under miscellaneous is confusing: if ==
> compares identity and not value, then it would seem to be
> very much changed from 2.x. If this is in the context of
> inequality operators, then it doesn't seem to be worth
> mentioning in the same sentence, especially if it hasn't
> actually changed from 2.x
>
> You've got everyone worried they'll have to import the
> "foo".equals(string) idiom from Java -- I can't imagine
> anyone seriously advocating for that horrid misfeature!

You're misreading it. The DEFAULT comparison for object types that don't override __eq__ compares like 'is', which is the same as the default in 2.x. Most familiar objects override __eq__ to compare by value (e.g. numbers, strings, lists, tuples, dicts etc.).

Sorry for the confusion! I don't know how else to phrase this.

Konstantin Yegupov

Posts: 1
Nickname: yk4ever
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 26, 2007 3:53 AM
Reply to this message Reply
How I'd like to see the unpopular "self" thingy resolved:

1. "from __syntax__ import selfless" makes self parameter implicit in all class method definitions. Someone may prefer it. If parameter named "self" is provided as first - ok, then it is explicit.

2. If "selfless" is not defined, all class method definitions that do not have "self" argument should generate a warning.

Other stuff:

3. Perhaps sets should be written as "s{1,2,3}". Empty set will be "s{}".

4. It would be nice to have "from __syntax__ import end", to make Ruby fans less bitchy. This would even allow one-line code, which may be required for some occasions.

5. Replacing ints with longs is bad for performance. How often people do really use long arithmetic?

6. Come to think of it, nobody uses complex numbers. Maybe they should be dropped from core?

Joe Tennies

Posts: 2
Nickname: rotund
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 26, 2007 10:01 AM
Reply to this message Reply
>>5. Replacing ints with longs is bad for performance. How often people do really use long arithmetic?

I thought that I would point out that for most people, int and long are actually the same. This is 32-bit Linux, 32 and 64 bit Windows (yes, long is 32 bit on 64-bit Windows... that's why most everything just works). I'm not sure about Intel or PowerPC Mac (I can guess PowerPC Mac is all 32-bit).

Also, keeping it simple is just nice.

Joe Tennies

Posts: 2
Nickname: rotund
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 26, 2007 1:11 PM
Reply to this message Reply
Ignore my previous post. Obviously I was thinking C long not Python long. Now I have to agree with the statement that I'm concerned about speed. Even if short-circuited for short numbers, this could be expensive.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Python 3000 Status Update (Long!) Posted: Jun 27, 2007 7:58 AM
Reply to this message Reply
> Ignore my previous post. Obviously I was thinking C long
> not Python long. Now I have to agree with the statement
> that I'm concerned about speed. Even if short-circuited
> for short numbers, this could be expensive.

I don't want to sound critical but just let people know that many of the requests (or concern) are out of ignorance and will probably not cause much reaction from core developers. If you have speed concerns about python longs you must have had those for the last 6 years (PEP 237) of python. In the last couple of releases a python int pretty much behaves like a long for all practical purposes. The only thing this new release will do is to remove the redundant constructor and the funny letter L.

Chuck Adams

Posts: 3
Nickname: chuckadams
Registered: Feb, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 27, 2007 2:20 PM
Reply to this message Reply
> "from __syntax__ import selfless"
[and others]

Suggestions out of the blue are not going to get traction on this blog discussion, and I think it's fair to warn that pretty much all the suggestions mentioned would not meet with a warm reception on python-ideas, let alone a PEP.

Ionel Maries Cristian

Posts: 1
Nickname: leonord
Registered: Jul, 2006

Re: Python 3000 Status Update (Long!) Posted: Jun 29, 2007 10:46 AM
Reply to this message Reply
is the lambda in py3k the same expression only lambda ?
it would be nice to have a lambda that can take statements and about anything a normal function could do

Adam Olsen

Posts: 11
Nickname: rhamph
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jun 30, 2007 2:30 PM
Reply to this message Reply
What is StandardException? Typo for StandardError? (StandardException seems to be used in Java).

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Python 3000 Status Update (Long!) Posted: Jun 30, 2007 3:57 PM
Reply to this message Reply
> What is StandardException? Typo for StandardError?
> (StandardException seems to be used in Java).

Yes. I'll correct this in the main text.

Cyril Slobin

Posts: 1
Nickname: slobin
Registered: Jul, 2007

Re: Python 3000 Status Update (Long!) Posted: Jul 10, 2007 10:47 AM
Reply to this message Reply
> 5) How about '{,}' for an empty Set()?

How about to introduce a special type Empty, which is subclass of both dict and set? Yes, I know, this is impossible in current python 2.x, but would it be still impossible in 3000? Even if not, this can be a special case. ("...aren't special enough...") The literal {} should be syntactic sugar for Empty(). Both isinstance({}, dict) and isinstance({}, set) should be True, x in {} should be False for every x, {} should support iterator interface and yield an empty sequence, and so on. And any modifying operation (remove, __setitem__) should change the type of an object to set or dict. Of course we should decide how to resolve ambiguity between set.update and dict.update. Very raw idea...

Ruben Reifenberg

Posts: 2
Nickname: ratsberg
Registered: Jun, 2007

Re: Python 3000 Status Update (Long!) Posted: Jul 11, 2007 3:01 AM
Reply to this message Reply
Suggestion: Scope Description Block

The scope description block (perhaps "restriction block") assigns limitations to names that appear in the scope.

def func_with_restricted_scope(foo, bar):
scope: # a keyword
foo: # sub block for the foo name
isinstance(foo, int)
foo < 77
foo < bar # restrict by combining values
# now the function body ...

This aims to be both a movement towards Design By Contact (DBC) in python, als well as a base for generic functions implementation. It aims to allow not only type restrictions but also complex restrictions combining values. (The signature annotations syntax (PEP 3107 ) seems to be less comprehensive, althought more handy - I'd embrace and use it when it comes implemented...)
The scope restrictions above limit the function scope. But this aims to be useable for other scopes, too. (In a class scope, the __slots__ may be a restriction that (how??) might belong into a scope description block. In a function scope, the return value might be restricted, e.g.with "return" keyword, as worked out in PEP 3107.)
The scope block may contain documentation for names, and 3rd party specific data, as worked out with PEP 3107, too:

bar:
"bar is a useless parameter" #a helpstring for bar
xtool: "parse_this" # named data. The 3rd-party tool "xtool" may be looking for the key "xtool_data"

The above example limits function arguments only (The semantics may be "check-at-method-entry-only"). Ignoring performance issues, it would be great when restricting any name appearing in the scope (requiring a check everytime when the value changes):

scope:
foo:
(...)
abc:
abc > 0 # abc is not a function parameter

# now the function body ...
abc = -1 # raise RestrictionViolation error


The idea overlaps -at least- with both PEP 3107, and the discussion about Interfaces (http://www.artima.com/weblogs/viewpost.jsp?thread=86641) . (If existing, please point me to a discussion where similar ideas were considered/rejected.)

William Baxter

Posts: 4
Nickname: baxissimo
Registered: Jul, 2007

Re: Python 3000 Status Update (Long!) Posted: Jul 31, 2007 5:36 PM
Reply to this message Reply
> isn't it python3kically obvious
> that {} is an empty set and {:} is an empty dict?

That's exactly what I was thinking, too.

William Baxter

Posts: 4
Nickname: baxissimo
Registered: Jul, 2007

Re: Python 3000 Status Update (Long!) Posted: Jul 31, 2007 5:57 PM
Reply to this message Reply
> > Any chance we could get rid of mandatory self in
> > classes, as long as everything is up for grabs?
>
> In just about every language I've seen that doesn't use
> such a scoping identifier, you'll find ad-hoc coding
> standards for marking class instance variables. For
> example prefix with "m_" or postfix with "_" in C++ is
> common.

Yes, and as someone pointed out, you don't _have_ to call it 'self'. You could call it 's':


def someMethod(s, other, args, here):
s.other = other
s.args = args
s.here = here


And with that, it's no more typing than the 'm_' convention seen frequently in C++ code.

That said, I still kind of like to use 'self' most of the time because it's easy to spot. And not too onerous in most cases. There are times, however, when I want to do repeated operations to a particular member of 'self'. And for that it would be really nice if there were a way to 'import' from self (or any other object) the way you can import from a namespace.

For example, instead of:


def voom(self, jolt):
self._number_of_volts += jolt
if not_safe_voltage(self._number_of_volts):
self._number_of_volts = min(self._safe_voltage,self._number_of_volts)


You could do:


def voom(self, jolt):
from self import _number_of_volts as v
v += jolt
if not_safe_voltage(v):
v = min(self._safe_voltage,v)


The example is somewhat contrived, but you get the idea. Sometimes you end up repeating self._some_long_member_name many times. With current Python the workaround is to use a temp and assign it back:


v = self._number_of_volts
... use v ...
self._number_of_volts = v


But it's easy to forget to set it back to the original value, and often you've got several such members you want to manipulate so you end up with:


v = self._number_of_volts
a = self._number_of_amps
p = self._current_parrot
k = self._current_shop_keeper
... use v ...
self._number_of_volts = v
self._number_of_amps = a
self._current_parrot = p
self._current_shop_keeper = k


which just seems like a big unnecessary violation of DoNotRepeatYourself.

Flat View: This topic has 47 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Python 3000 Status Update (Long!) Previous Topic   Next Topic Topic: Scala steadily marches towards world domination!

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use