views:

1141

answers:

13

I've just read the What's New in Python 3.1 text (and I like many things). What's your idea of the thing that didn't go there but you would like to see in the future Python versions?

+1  A: 
import invisible_pink_unicorn
SilentGhost
import visible_pink_unicord is what I would prefer :)
ilya n.
These sound like great modules, but please follow PEP 8 guidelines for module names and trim the length down, it'll be a problem when running in DOS. :)
Joel
No way, stone you to death yehova. Its "import flying_spaghetti_monster"
Lothar
+2  A: 

The ability to specify that arguments can be passed only by keyword.

A dict.get() method that takes a callable instead of an object, the callable's result would be returned if the key doesn't exist.

Richard Levasseur
As for the second one, I believe there is a defaultdict class in collections that does that
ilya n.
Yeah, but from what i saw of default dict, it uses a void factory function, so you can't use the key to determine the return type, nor can you special case the return value for that specific call to get. The wish it to simplify the `if key not in d: ... else: ...` for when the default value is more complex then a simple scalar value.
Richard Levasseur
You can try to use a `lambda` for your second thing
cool-RR
The first is already implemented in 3.1: `def f(*, a, b, c)`
Philipp
A: 

Being able to define a class methods with:

def self.foo()

instead of

def foo(self)

Christian
what exactly would this allow you to do?
TokenMacGuy
it would let people write clearer code; it can be confusing to some people to define methods with 3 args and call it with 2, etc.
Kevlar
It would also make it easier to teach people Python.
Christian
Totally.agree. The self thing is confusing to many people.
ilya n.
Baaa. One of the things that makes Python so great is the utter lack of ifs-ands-and-buts in the language. self as a first argument to a bound instance method makes perfect sense once explained, and is one less bit of magic that Python needs to have. "/".join(some_list) == str.join("/", some_list)
gahooa
Or you could just add the @classmethod decorator to the method and you don't even need the self parameter. It works similar to the way you'd require keywords in other languages. Also, if you want to implement static methods without abusing the singleton pattern you can use the @staticmethod decorator.
Evan Plaice
@Evan With `@classmethod`, it has the `cls` first argument which works exactly like `self`
aaronasterling
+3  A: 

I think something similar to F#'s pipeline operator would be pretty useful.

Jason Baker
Python doesn't even have the normal function composition operator. Once you start adding operators on functions you want to have them all (not only (|>) but (>>) and (.), at least!). I wouldn't mind having them, but Python lacks the concise notation of lambdas that functional languages have which makes them less useful.
THC4k
they wouldn't be less useful... they'd just be more cumbersome
Timothy
+7  A: 

A module keyword for specifying module scope, analogous to self for class instance scope. It would eliminate I think all use cases for global.

Intead of:

sequenceNumber = 0

def increment():
    global sequenceNumber
    sequenceNumber += 1

It would be like:

sequenceNumber = 0

def increment():
    module.sequenceNumber += 1

Also, in the same vein, a package keyword to reference things defined in the __init__.py for the current submodule.

darkporter
One use case you miss though is putting code formerly on a module level into a function: I find using `global` keyword here to be easier on the eye.
ilya n.
I agree with the 'module' keyword. It's nice to be able to contain a bunch of values within a module without putting making them global. I'd prefer to (almost) never put anything in global scope if possible, especially in the case of library development where there's a particular interest in making modules a self-contained unit of functionality. The 'module' keyword would solve this issue without having to create a utility class for the module to contain these vales.
Evan Plaice
Do people upvoting this understand how the `global` keyword works? python doesn't have __a__ global scope. All `global` does is make it global _in the module_. This is why each function has it's own `func_globals` dict that captures the globals of _the module it's defined in_.
aaronasterling
At any rate, a module can always import itself and refer to itself in that way.
aaronasterling
A: 

the self argument is something people have been fretting about for almost as long as python exists. the solution discussed here (to require people to write def self.f():), however, is troublesome and not resolvable without more magic behind the scenes—this mainly because no self exists at class definition time. and i still have to write it out!

i would prefer a solution where self is taken out of the method definition and magically injected into the method namespace:

class X:
  def f( x, y, z ):
    return self.g( x * y * z )

the big advantage of this would be that method signatures will closely match function signatures; the big disadvantages are that (1) now it becomes a preset, not a choice of the developer, how to name their instance variable, and that (2) there might be pathological cases where this kind of magic causes troubles of the kind that riddle javascript’s magic this variable—which requires a PHD in computer science to use correctly. and i am very sure BDFL will come up with a whole bunch of more kinks that this solution has.

flow
ah, and please please please a reasonable and fast asynchronous http library for non-blocking http servers and clients. this is so underrated these days.
flow
There's no need for a new feature. Python can already do what you're describing. See the @classmethod decorator. There's also the @staticmethod for methods that work like static methods in other languages (IE, they're globally accessible within a classes namespace without instantiating an object of the class).
Evan Plaice
+2  A: 

I hope they get the reworked re module ready until then. The old one lacks quite a few features and has some subtle bugs/misfeatures.

Tim Pietzcker
A: 

1) global variable declaration

global counter = 0
def IncrementCounter():
    counter += 1

2) Type declaration

def int GetAge(mx.DateTime birthDate):
    pass

Correction: If you want the current behavior (dynamic typing), just do :

def GetAge(birthDate):

But it will be difficult to know what your function expects as input and returns as output. And IDE auto-completion will be useless. Not talking about exceptions raised that force others to read your code to know exactly what your function needs and returns.

Comment : I don't understand how you do synthax highlighting.

Note: The editor don't works well.

Added comment : Do you prefer to make this for every function :

def GetAge(birthDate):
    if not isinstance(birthDate, mx.DateTime):
        raise InvalidParameter('birthDate', 'The birthDate parameter should be of type 'mx.DateTime')

??? sorry, it seems you got the global keyword completely wrong or you forgot to read the manual... even the second part does not make sense: declaring the return type of a function implies that functions are no more first class citizens and that dynamic typing is gone.
Adrien Plisson
no, i know what global means. but this way, you will not have to declare the global variable for each function. Yes, it's what I want : dynamic typing to be gone. If you want dynamic typing, just declare the function as object type.
do you know that i gives many problems when you don't know what a function expect as input and gives as output ? you should do more C programming language to understand
and this way, ides and compilers will be able to help us better than it is now
@user0980923452334543575624454, if you want to program in C, then program in C. if you want to program in Python, accept, use and appreciate the strengths of dynamic typing.
aaronasterling
you should change your mind. dynamic typing has always been problematic for complex softwares. declaring our variable types is the base of programming languages. microsoft has understand it with it's visual basic 6 that has been changed to visual basic.net with type declaration. before that, the behavior of vb was like python : no need to declare variable types. i don't understand why you don't want variable declaration types. it could be easier for everyone to do python, you don't know how.
+2  A: 
David Morrissey
+4  A: 

an or clause on loops to make empty iterable flags go away just like the else clause makes not found flags go away.

for item in iterable:
    if hasattr(item, 'foo') and getattr(item, 'foo') == value:
        break
or:
    raise Exception("You gave me an empty iterable :( ")
else:
    raise Exception("I didn't find what you're looking for :( ")
print("wOOt! I found what you're looking for! :) ")

That's just awesome. And it doesn't break any existing code. The else clause runs only if there is no or clause or there is an or clause and the iterable isn't empty.

aaronasterling
+3  A: 

Multithreading:

  • I'd like to see the check interval gone.
  • Progress towards abandoning the GIL.
  • Fast recursive locks would be a nice thing to have when proper threading is implemented, also.

More careful consideration of POSIX semantics. Some kinks remain to be fixed, such as pending signals being inherited by child processes (as in 9535).

Suspension of all language syntax and built-in changes and work towards preserving semantics, for at least one year. This can give time to alternative implementations to get caught up on new features, resolving bugs, aid in wide adoption of Python 3.x (don't forget that most distributions are still in 2.5, sadly), focus more on the libraries, standard or not (is re ever going to be rewritten?).

Michael Foukarakis
I would increase the time span to five years. Of course only for the main interpreter semantics and not for libraries. Thats still half the frequence of C and the same as C++.
Lothar
Maybe so. Guido is pushing for a time span of two years. I think of one year as a bare minimum, or a good starting point if you will.
Michael Foukarakis
+1  A: 

A new keyword "override" that tells to the compiler that a function should override an existing function or raise a compilation error. This keyword is not mandatory to override a function.

class A():
    def MyFunction():
        pass

class B(A):
    def override MyFunction():
        pass

So if MyFunction is removed from class A, a compilation error is raised.

what would a use case for this be?
aaronasterling
all my suggestions are to avoid problems, and simplify my life. we need more errors catched at compilation time.
You could probably hack something like this together using metaclasses and a method decorator.
Quartz
A: 

Call me crazy, but I would like to see some of the configurable GC and Thunk object space work going on in PyPy brought back into CPython. For example, the ability to declare an infinite list as lazy would be nicer than rigging it up so it appears lazy using an iterator and takewhile. To have this style of computation built in will eliminate much of the following code. In addition, I could possibly use this feature to write the following interator in a listcomp and take an arbitrary index.

from itertools import takewhile

class Fib(object):
    def __init__(self):
        self.n = 0
        self.n_1 = 1

    def __iter__(self):
        return self

    def next(self):
        next = self.n + self.n_1
        self.n = self.n_1
        self.n_1 = next
        return next


def fib_n(n):
    fib = Fib()
    return takewhile(lambda x: x < n, fib)

print list(x for x in fib_n(10))

I don't know, call me functional, but I like the ability to declare infinite data structures.

ps. More thought on this makes me think I can get some of what I want using existing methods in the stdlib, but I still would like it all to be in one standard module.

dcolish