关于Python的想法 [英] Thoughts about Python

问题描述

嗨


我不必谈论Python的美妙之处及其清晰的

可读语法...但是有一个

学习Python的一些事情让我感到震惊。


我收集了这些想法。我确信有很多关于问题的讨论

这里提到的。但我有这个想法没有

查看任何论坛或任何东西......这是一种反馈。


感谢这种奇妙的语言，
Marco


***问题：笨拙的静态类方法


为了创建一个静态方法，我们必须使用一个内置的

staticmethod（函数）：


class C（对象）：

def f（arg1，arg2 ,. ..）：...

f = staticmethod（f）


为什么？ 静态的特征是静态的特征。方法是：它无法访问任何

实例变量。下面的课程更容易阅读和理解

静态方法是什么...作为一个积极的副作用：自我是

不可用它可以''使用！


class c（对象）：

def staticMethod（arg1，arg2，...）：

#self没有交给...因此我不能使用实例变量

pass

def normalMethod（self，arg1，arg2，...）：

通过


没有必要内置...据我所知：内置是

a解决方法.. 。


***问题：班级笨拙的属性


属性（[fget [，fset [，fdel [，doc]]] ]）


class C（对象）：

def getx（self）：return self .__ x

def setx（self ，值）：self .__ x = value

def delx（self）：del self .__ x

x = property（getx，setx，delx，" I'm） ''x''属性。"）

我不喜欢这个。没有必要，因为它通过查看类/代码来描述应该清楚的东西。一个

约定会使语法更清晰，更直观，并且通过

查看你会知道的方法的定义：这是一个

吸气剂，二传手或者删除者。我的建议：


所有的getter都以__get__开头

所有的setter都以__set__开头

所有的删除器都以__del__开头


如果有人使用：


prop.x = 5

Python检查var是否''x' '存在于道具上。如果确实如此 - 它是

设置。如果它不存在Python检查''__set__x''如果它不存在
存在...引发AttributeError：

class PropertyExample（对象）：

"""属性概念的演示类。


此类后续使用如下：

prop = PropertyExample（）

prop.x = 5 #__set__x（self，5）在幕后调用

print prop.x＃__get__x（self）在幕后调用

del prop.x＃__ del__x（self）在幕后调用""


def __init __（self）：

self .__ x =无


def __del__x（个体经营）：

del self .__ x

def __get__x（self）：

返回self .__ x

def __set__x（自我，值）：

self .__ x = value


***问题：许多内置组件不是必需的


许多内置组件不是必需的。仅举几例：min / max / len


此功能应在课程中定义：


[" I"，" ;喜欢，，Python，。len（）

我.len（）

{1：我，2： " like"，3：" Python"}。len（）

（1,2,3,4）.len（）


" ;扔掉这个内置的内容会再次扁平化学习

曲线（你不必学习那么多内置）...这些

函数属于同类他们自然会在那里受到期待。

语言的一个弱点是（Visual）Basic，PHP，...是它的有效载荷

的可用函数...... Python'' s OO有助于减少需要

的功能。

***问题：元组不是必需的


从长远来看扔掉它们 - 现在让它们被剥夺。这很难说是有利于元组的。可能有两个原因：


1.它比列表快很多

2.我们不能没有不可变列表

缺点：


1.我认为元组不会带来很大的性能提升。

2. Python使这么多软的惯例（例如：不要使用

变量/方法和2个前导下划线）但是当涉及元组

时，不可变问题非常重要...为什么？我希望元组会在P3K中消失
。

***问题：builtins list（）dict（）...


列表，字典，str，int，float是内置函数...


myList = list（）

myDict = dict （）

myString = str（45）


list-function实例化一个新列表......实际上什么都没有

但是重载的List类。为什么交付功能？在一个

OO环境中，它应该更多的是一个类的实例而不是一个函数，并且类以一个大写字母开头：


myList = List（）

myDict = Dict（）

myString = String（45）

Hi

I don''t have to talk about the beauty of Python and its clear and
readable syntax... but there are a few things that striked me while
learning Python.

I have collected those thoughts. I am sure there are many discussions
on the "problems" mentioned here. But I had this thoughts without
looking into any forums or anything... it is kind of feedback.

Thanks for this marvellous language,
Marco

*** Problem: clumsy static class methods

In order to create a static method we have to use a the builtin
staticmethod(function):

class C (object):
def f(arg1, arg2, ...): ...
f = staticmethod(f)

Why? The speciality of a "static" method is: It has no access to any
instance vars. The following class is easier to read and understand
what a static method is about... as a positive side-effect: self is
not available and it can''t be used!

class c (object):
def staticMethod(arg1, arg2, ...):
# self is not handed in... hence I can''t use the instance vars
pass
def normalMethod(self, arg1, arg2, ...):
pass

There is no need for the builtin... as I understand it: the builtin is
a workaround...

*** Problem: clumsy properties for classes

property( [fget[, fset[, fdel[, doc]]]])

class C(object):
def getx(self): return self.__x
def setx(self, value): self.__x = value
def delx(self): del self.__x
x = property(getx, setx, delx, "I''m the ''x'' property.")
I don''t like this one either. It is not necessary because it describes
something that should be clear by looking at the class/code. A
convention would make the syntax clearer and more intuitive and by
looking at the definition of a method you would know: This is a
getter, setter or deleter. My proposal:

all getters start with __get__
all setters start with __set__
all deleters start with __del__

If someone uses:

prop.x = 5

Python checks whether the var ''x'' exists on prop. If it does - it is
set. If it doesn''t exist Python checks for ''__set__x'' if it doesn''t
exist either... a AttributeError is raised:
class PropertyExample(object):
"""A demonstration class for the property idea.

This class is used afterwards as follows:
prop = PropertyExample()
prop.x = 5 # __set__x(self, 5) is called behind the scenes
print prop.x # __get__x(self) is called behind the scenes
del prop.x # __del__x(self) is called behind the scenes"""

def __init__(self):
self.__x = None

def __del__x(self):
del self.__x
def __get__x(self):
return self.__x
def __set__x(self, value):
self.__x = value

*** Problem: Many builtins are not necessary

Many builtins are not necessary. To name a few: min / max / len

This functions should be defined on the class:

["I", "like", "Python"].len()
"I".len()
{1:"I", "2":"like", 3:"Python"}.len()
(1,2,3,4).len()

"Throwing away" this builtins would flatten the alreay flat learning
curve once more (you don''t have to learn that many builtins) ... these
functions belong to the class and they are naturally expected there.
One weakness of a language as (Visual)Basic, PHP, ... is its payload
of available functions... Python''s OO helps here to diminish the need
for lots of functions.
*** Problem: tuples are not necessary

Throw them away in the long run - for now make them depracted. It is
hard to argue in favour of tuples. There might to 2 reason:

1. It is MUCH faster than a list
2. We can''t live without an immutable list

Cons:

1. I don''t think that tuples deliver a big performance gain.
2. Python makes so many "soft" conventions (eg.: don''t use
vars/methods with 2 leading underscores) but when it comes to tuples
the immutable issue is very important... why? I hope the tuples will
disappear in P3K.
*** Problem: builtins list() dict() ...

A list, a dictionary, a str, an int, a float are builtin functions...

myList = list()
myDict = dict()
myString = str(45)

The list-function instantiates a new list... it is actually nothing
but an overloaded List class. Why are the handed in as functions? In a
OO environment it should be more the instatiation of a class rather
than a function and classes start with an uppercase letter:

myList = List()
myDict = Dict()
myString = String(45)

推荐答案

PP**********@spammotel.com （ Marco Aschwanden写道：

PP**********@spammotel.com (Marco Aschwanden) writes:

嗨

我不必谈论Python的美妙之处及其清晰可读的语法。 ..但是在学习Python的过程中有一些事情让我感到震惊。

我收集了这些想法。我相信在问题方面有很多讨论。这里提到的。但我有这个想法，没有
查看任何论坛或任何东西......这是一种反馈。

感谢这种奇妙的语言，
Marco
staticmethod（函数）：

C级（对象）：
def f（arg1，arg2，...）：...
f = staticmethod（f）


参见PEP 318 （以及关于python-dev的最新讨论）。

为什么？ 静态的特征是静态的特征。方法是：它无法访问任何实例变量。下面的课程更容易阅读和理解
静态方法是什么......作为一个积极的副作用：自我是不可用的，它不能被使用！

class c（对象）：
def staticMethod（arg1，arg2，...）：
#self未交付...因此我无法使用实例变量
传递
def normalMethod（self，arg1，arg2，...）：
传递

不需要内置...我理解它：内置是一个解决方法...


自我有什么特别之处？我真的不喜欢

参数名称来控制这种行为改变的想法。

***问题：类的笨拙属性

property（[fget [，fset [，fdel [，doc]]]]）

C类（对象）：
def getx（self）：return self .__ x
def setx（self，value）：self .__ x = value
def delx（self）：del self .__ x
x = property（getx，setx，delx，"我是''x''属性。"）

我不喜欢这个。没有必要，因为它通过查看类/代码来描述应该清楚的东西。
约定会使语法更清晰，更直观，并且通过查看您将要知道的方法的定义：这是一个getter，setter或deleter。我的建议：

所有的getters都以__get__开头
所有的setter都以__set__开头
所有的删除器都以__del__开头

如果有人使用：

prop.x = 5
Python检查prop上是否存在varx。如果确实如此 - 它已经设定好了。如果它不存在Python检查''__set__x''如果它不存在......则引发AttributeError：

class PropertyExample（object）：
"""属性概念的演示类。

此类后来用于如下：
prop = PropertyExample（）
prop.x = 5＃__set__x（self，5）在幕后调用
print prop.x＃__get__x（self）在幕后调用
del prop.x＃__ del__x（self）在幕后调用 "

def __init __（self）：
self .__ x =无

def __del__x（个体经营）：
del self .__ x
def __get__x（个体经营）：
返回自我.__ x
def __set__x（自我，价值）：
自我.__ x =价值


你似乎非常喜欢神奇的名字...


顺便说一句，Python 2.2引入了静态方法和

属性的能力并且有意识地决定不添加相同

的语法，直到有使用这些东西的经验。所以我们知道

这里有一些不适，但现在还不清楚（对我来说，至少
）什么是好的语法*是*。我希望你不要太冒犯，如果我说b $ b说你的建议看起来并不是很好。

***问题：很多内置都不是必需的b $ b

Pah。所以呢？如果你想要minimailty计划在那里====>

很多内置都没有必要。仅举几例：min / max / len
这个功能应该在课堂上定义：


说你！


[...]

***问题：元组不是必需的


说你！这里有一个提示：hash（[]）。


[...] ***问题：builtins list（）dict（）......

myList = list（）
myDict = dict（）
myString = str（45）

Hi

I don''t have to talk about the beauty of Python and its clear and
readable syntax... but there are a few things that striked me while
learning Python.

I have collected those thoughts. I am sure there are many discussions
on the "problems" mentioned here. But I had this thoughts without
looking into any forums or anything... it is kind of feedback.

Thanks for this marvellous language,
Marco

*** Problem: clumsy static class methods

In order to create a static method we have to use a the builtin
staticmethod(function):

class C (object):
def f(arg1, arg2, ...): ...
f = staticmethod(f)
See PEP 318 (and current discussion on python-dev).
Why? The speciality of a "static" method is: It has no access to any
instance vars. The following class is easier to read and understand
what a static method is about... as a positive side-effect: self is
not available and it can''t be used!

class c (object):
def staticMethod(arg1, arg2, ...):
# self is not handed in... hence I can''t use the instance vars
pass
def normalMethod(self, arg1, arg2, ...):
pass

There is no need for the builtin... as I understand it: the builtin is
a workaround...
What''s so special about self? I really don''t like the idea of
argument names keying this kind of change in behaviour.
*** Problem: clumsy properties for classes

property( [fget[, fset[, fdel[, doc]]]])

class C(object):
def getx(self): return self.__x
def setx(self, value): self.__x = value
def delx(self): del self.__x
x = property(getx, setx, delx, "I''m the ''x'' property.")
I don''t like this one either. It is not necessary because it describes
something that should be clear by looking at the class/code. A
convention would make the syntax clearer and more intuitive and by
looking at the definition of a method you would know: This is a
getter, setter or deleter. My proposal:

all getters start with __get__
all setters start with __set__
all deleters start with __del__

If someone uses:

prop.x = 5

Python checks whether the var ''x'' exists on prop. If it does - it is
set. If it doesn''t exist Python checks for ''__set__x'' if it doesn''t
exist either... a AttributeError is raised:
class PropertyExample(object):
"""A demonstration class for the property idea.

This class is used afterwards as follows:
prop = PropertyExample()
prop.x = 5 # __set__x(self, 5) is called behind the scenes
print prop.x # __get__x(self) is called behind the scenes
del prop.x # __del__x(self) is called behind the scenes"""

def __init__(self):
self.__x = None

def __del__x(self):
del self.__x
def __get__x(self):
return self.__x
def __set__x(self, value):
self.__x = value
You seem really fond of magic names...

By the way, Python 2.2 introduced the capacity for staticmethods and
properties and consciously decided not to add syntax for the same
until there was some experience in using these things. So it''s known
that there is some discomfort here, but it''s not yet clear (to me, at
least) what a good syntax *is*. I hope you''re not too offended if I
say that your suggestion doesn''t seem instantly wonderful.
*** Problem: Many builtins are not necessary
Pah. So what? If you want minimailty scheme is over there ====>
Many builtins are not necessary. To name a few: min / max / len

This functions should be defined on the class:
Says you!

[...]
*** Problem: tuples are not necessary
Says you! Here''s a hint: hash([]).

[...] *** Problem: builtins list() dict() ...

A list, a dictionary, a str, an int, a float are builtin functions...

myList = list()
myDict = dict()
myString = str(45)

Pedantry：不，他们不是，他们是内置类型。


我想你可能会期待Python的其他东西，而不是它的b $ b。你没有提出任何建议是完全荒谬的，只是，好吧，

略微没有Pythonic。我建议你继续使用Python几周再花几个星期再读一遍你的清单。


干杯，

mwh


-

MARVIN：哦，亲爱的，我想你会再次发现现实已经眨眼了。

- - Hitch-Hikers银河系指南，第12集

Pedantry: no they''re not, they''re builtin types.

I think you might be expecting something other of Python than what it
is. Nothing you suggest is completely ridiculous, just, well,
slightly un-Pythonic. I suggest you continue using Python for a few
more weeks and read your list again.

Cheers,
mwh

--
MARVIN: Oh dear, I think you''ll find reality''s on the blink again.
-- The Hitch-Hikers Guide to the Galaxy, Episode 12

PP ********** @ spammotel.com （Marco Aschwanden）写在

新闻：15 ************* *************@posting.google.c om：

PP**********@spammotel.com (Marco Aschwanden) wrote in
news:15**************************@posting.google.c om:

我收集了这些想法。我相信在问题方面有很多讨论。这里提到的。但我有这个想法没有
查看任何论坛或任何东西......这是一种反馈。


我认为你应该花一点时间阅读PEP和python-dev

邮件列表档案。你之前已经讨论了很多你所说的话，

如果你能参加早期的讨论并且

然后看看你的想法引导你的话会很好。

***问题：笨拙的静态类方法

这在其他地方已被广泛讨论过，各种解决方案已被提出。

。

***问题：类的笨拙属性

至于静态方法，已经提出了各种改进方法。你应该阅读有关python-dev的讨论，看看各种观点。

***问题：很多内置都没有必要

很多内置是没有必要的。仅举几例：min / max / len
这个函数应该在类上定义：

[" I"，" like"，" Python" ] .len（）
我.len（）
{1：我，2：喜欢，3：
（1,2,3,4）.len（）


min和max作为内置的优点是它们适用于任何

序列。特别是它们在迭代器上工作。具有将

应用于任意序列的函数可避免大量潜在的代码重复。

扔掉这个内置的内容会再次平息学习曲线（你不必学习很多内置）......这些功能属于课堂，他们自然会在那里得到它们。语言的一个弱点是（Visual）Basic，PHP，...是其可用功能的有效载荷...... Python的OO有助于减少对许多功能的需求。


我还会先扔掉其他内置物。请注意，你不能实际抛出任何这些内置的东西：Pythons的一个强大优势

是保持向后兼容性的长度。一些不太有用的内置组件被降级为

文档的回水，但在可预见的将来它们仍然是内置的。


***问题：没有必要使用元组

从长远来看扔掉它们 - 现在让它们被删除。支持元组很难争论。可能有两个原因：

1.它比列表快得多
2.我们不能没有不可变的列表生活


忘记速度和记忆差异。元组作为

单独类型的主要参数是用作字典键。你如何建议在没有元组的情况下处理

字典键？

***问题：builtins list（）dict（）......

列表，字典，str，int，float是内置函数...


不，他们不是。它们是类型，而不是函数。

myList = list（）
myDtring = dict（）
myString = str（45）

列表 - 函数实例化一个新列表......它实际上没有什么
但是重载的List类。为什么交付功能？在一个/或OO环境中，它应该更像是一个类的实例，而不是一个函数，而类以一个大写字母开头：

myList = List（）
myDict = Dict（）
myString = String（45）

I have collected those thoughts. I am sure there are many discussions
on the "problems" mentioned here. But I had this thoughts without
looking into any forums or anything... it is kind of feedback.
I think you should spend a bit of time reading the PEPs and the python-dev
mailing list archives. A lot of what you say has been discussed previously,
and it would be good if you could take the earlier discussion on board and
then see where your thoughts lead you.

*** Problem: clumsy static class methods
This has been widely discussed elsewhere and various solutions have been
proposed.

*** Problem: clumsy properties for classes
As for static methods various ways to improve this have been suggested. You
should read the discussions on python-dev to see the various viewpoints.

*** Problem: Many builtins are not necessary

Many builtins are not necessary. To name a few: min / max / len

This functions should be defined on the class:

["I", "like", "Python"].len()
"I".len()
{1:"I", "2":"like", 3:"Python"}.len()
(1,2,3,4).len()
The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions that apply
to an arbitrary sequence avoids a lot of potential code duplication.
"Throwing away" this builtins would flatten the alreay flat learning
curve once more (you don''t have to learn that many builtins) ... these
functions belong to the class and they are naturally expected there.
One weakness of a language as (Visual)Basic, PHP, ... is its payload
of available functions... Python''s OO helps here to diminish the need
for lots of functions.
There are other builtins I would throw away first. Note that you can''t
actually throw any of these builtins away: one of Pythons great strengths
are the lengths it goes to to maintain backward compatibility. Some of the
less useful builtins are being relegated to backwaters of the
documentation, but they will remain as builtins for the foreseeable future.


*** Problem: tuples are not necessary

Throw them away in the long run - for now make them depracted. It is
hard to argue in favour of tuples. There might to 2 reason:

1. It is MUCH faster than a list
2. We can''t live without an immutable list
Forget the speed and memory difference. The main argument for tuples as a
separate type are to use as dictionary keys. How do you propose to handle
dictionary keys without tuples?

*** Problem: builtins list() dict() ...

A list, a dictionary, a str, an int, a float are builtin functions...
No they aren''t. They are types, not functions.

myList = list()
myDict = dict()
myString = str(45)

The list-function instantiates a new list... it is actually nothing
but an overloaded List class. Why are the handed in as functions? In a
OO environment it should be more the instatiation of a class rather
than a function and classes start with an uppercase letter:

myList = List()
myDict = Dict()
myString = String(45)

所以他们不遵循你的命名约定。如果这对你来说是个大问题，那么在你自己的程序中添加一些新的全局变量。类型''文件''

已经别名为''open''。你不能删除现有的内置组件（因为

会破坏库），但没有什么可以阻止你在__builtin__模块中添加你的

或者作为一个单独的模块包含

您的别名。


FWIW，我同意存在的内置不是类型

名称---他们经常与''明显''变量名称碰撞，而b / b蟒蛇新人选择这些名称，然后他们想知道为什么他们打电话给''str''打击

当他们使用变量''str''之前几行时。

So they don''t follow your naming convention. If this is a big problem for
you, then add some new globals in your own programs. The type ''file'' is
already aliased as ''open''. You can''t remove the existing builtins (since
that would break the library), but there is nothing to stop you adding your
own either in the __builtin__ module, or as a separate module containing
your aliases.

FWIW, I agree that the builtins that exist aren''t the best choice for type
names --- too often they collide with the ''obvious'' variable names that
python newcomers choose and then they wonder why their call to ''str'' blow
up when they used a variable ''str'' a few lines earlier.

Duncan Booth< [e-mail]>写道：

Duncan Booth <[e-mail]> writes:

PP ********** @ spammotel.com （Marco Aschwanden）在
新闻中写道：15 ************************** @ posting.google .c om：

PP**********@spammotel.com (Marco Aschwanden) wrote in
news:15**************************@posting.google.c om:

***问题：许多内置组件不是必需的

许多内置组件不是必需的。仅举几例：min / max / len
这个函数应该在类上定义：

[" I"，" like"，" Python" ] .len（）
我.len（）
{1：我，2：喜欢，3：
（1,2,3,4）.len（）

*** Problem: Many builtins are not necessary

Many builtins are not necessary. To name a few: min / max / len

This functions should be defined on the class:

["I", "like", "Python"].len()
"I".len()
{1:"I", "2":"like", 3:"Python"}.len()
(1,2,3,4).len()

minins和max作为内置函数的优点是它们适用于任何序列。特别是它们在迭代器上工作。具有适用于任意序列的函数可以避免大量潜在的代码重复。

The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions that apply
to an arbitrary sequence avoids a lot of potential code duplication.

你的意思是用户端的代码重复吗？或者代码重复在
Python的实现中？在后一种情况下，对于成千上万的开发人员来说，使用不一致的方法/函数使用它似乎很奇怪

只是为了在Python的源代码中保存几行代码。


对我来说，Python的内置函数到目前为止并不是一个问题，但我承认

我从来不理解为什么astring。 len（）不起作用。

Do you mean code duplication on the user side? Or code duplication in
Python''s implementations? In the latter case, it seems strange to
force inconsistent method/function usage on thousands of developers
just in order to save a couple of lines in Python''s source code.

To me, Python''s builtins are by far not a "problem", but I admit that
I never understood why astring.len() doesn''t work.

这篇关于关于Python的想法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！