.
It is desirable, in my opinion, that interactive behaviour be as
identical as possible as script behaviour: the automatic printing of
interactive mode is already much magic that newcomers need to sort out.
--
François Pinard http://pinard.progiciels-bpi.ca
__
. Programmers
not being in the first two sets do not require so much protection: for
the clever ones, because the probability of clashes between neologisms
is much smaller than the probability of clashes with usual natural
language words; for the randomising programmers, well, because they do
no
[Guido van Rossum]
>On 12/14/05, François Pinard <[EMAIL PROTECTED]> wrote:
>> I would like that PEP 0008 add some cement around this idea that common
>> English words, properly spelled, which are likely to be user variable
>> names, be avoided whenever reasonabl
, args)" with "func(*args)".
- Replacing "for line in file.readlines():" with "for line in file:".
- Replacing "for key in dict.keys():" with "for key in dict:".
- Replacing "if has_key(dict
[Phillip J. Eby]
>At 09:53 AM 12/13/2005 -0500, François Pinard wrote:
>>Everybody here agrees that this style makes the code much less legible.
>I hope you mean, "here at your company or organization", as I disagree. :)
Yes, of course! Sorry for the ambiguity.
--
of the form "from HELL import *". :-)
But this gets a bit far from the original topic. Let's drop the matter
here as not being much more of general interest, or else, let's switch
to private email.
ut
it only goes a little bit at a time. We should probably suffer taking
the time, dive in it all, and get rid of this style once and for all...
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
[Ian Bicking]
>Barry Warsaw wrote:
>Just like I wouldn't like someone using "self" outside of the first
>argument of instance methods.
A tiny nit. Within __new__(cls, ...), I find quite legible writing:
self = BASECLASSE.__new__(cls, ...)
and using it afterwar
simple and clean meaning, like the real base of the exception hierarchy.
Second, as a bare "except:" is not considered good practice on average,
it would be counter-productive trying to figure out ways to make it more
frequently _usable_.
--
François Pinard http://pinard.pro
ok log -t ARG2 ARG1", where ARG1
and ARG2 are arguments given to the pre-commit script.
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
this
world would love being as comfortable as possible using Python, while
naming identifiers naturally. It is not so unreasonable that we keep
some _hope_ that Guido will soon choose to help us all, not only me.
--
François Pinard http://pinard.progiciels-bpi.ca
__
or the file where you want
substitutions. That property is named "svn:keywords" and its value
decides which kind of substitution you want to allow.
This is all theory for me, I never used them.
--
François Pinard http://pinard.progiciels-bpi.ca
_
[Martin von Löwis]
> My canonical example is François Pinard, who keeps requesting it,
> saying that local people where surprised they couldn't use accented
> characters in Python. Perhaps that's because he actually is Quebecian
> :-)
I presume I should comment a bit
[Martin von Löwis]
>Without a file, I wouldn't know how to edit the property, so I would
>probably do
>svn propget svn:ignore . > ignores
>vim ignores
>svn propset svn:ignore -F ignores .
>rm ignores
You can use `svn propedit' (or `svn pe').
--
Franço
[Raymond Hettinger]
> > >> > Even better if the lines for a particular piece of code don't
> > >> > have to all come from the same file.
> YAGNI
I surely needed it, more than once. Don't be so assertive. :-)
--
Franço
s generated from more than one original source
file (referring to the `#line' directive message, a little earlier this
week). For example, think include files.
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-D
through generated Python for finding the real source as
referenced by comments.
Yet, granted also that the need has not been frequent, for me.
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
h
s other language norms, and
> simplifies/speeds-up the generated code.
The summary reduces to: "Returning only Booleans would speed-up the
generated code, once in a while."
Now, could we evaluate that speed up on the average code, like on the
Python library say? It might not be worth
ments,
and faster argument processing, the latter would win instantly.
> > ditching them thanks to the pain they caused in the AST branch.
> Changing the grammar for the convenience of a particular AST
> implementation carries zero weight with me -- that is the tail wagging
> the dog.
A v
ng full i18n for Template strings.
Yet,
"The file %(filename)s in directory %(dir)s is read only" % vars()
is already usable. The need being already filled without Template
strings, it could hardly be presented as a motivation for them. :-)
--
François Pinar
Let me correct two typos (I had to leave in a rush).
[François Pinard]
> [...] Let's consider that `print' (or whatever) is a Python function,
> not negotiable. It should likely be.
The "It" refers to `print' being a Python function, not the negotiability.
&g
which could be seen as similarly
encompassing. Logo and a few others also have parentheses-less function
calls, yet they may be week at handling functions as first-class
objects. (And besides, I'm far from overly liking them! :-).
--
François Pinard http://pinard.progiciels-bpi.ca
_
could
emulate a Turing Machine, but it at least addressed the Halting Problem!
One-who-happily-forgot-all-bout-this-ly yours...
P.S. - How is this related to Python? Luckily! -- that is: *not*! :-)
--
François Pinard http://pinard.progiciels-bpi.ca
ractices in this particular case,
even if this might hurt good coders once in a while. But I'm not sure!
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
we almost never need it in practice. "type" is annoying as a name (yet
very nice as a concept), as if it was free to use, it would often serve
to label our own things. The fact is we often need the built-in.
Python should not choose common Engli
[Donovan Baarda]
> It is true that some well designed/developed software becomes reliable
> very quicky. However, it still takes heavy use over time to prove that.
There is wisdom in your say! :-)
--
François Pinard http://pinard.progiciels-
eases, to be qualified as good. While it might be true on average,
this is not necessarily true: some packages need not so many steps for
becoming very usable, mature or stable. (Note that I'm not asserting
anything about Monotone, here.) We should merely keep an open mind.
--
Franç
ut at first glance, Monotone does not
seduce me. On the other hand, the two guys saying good about Monotone
are well informed (and also well known), so I would not dismiss their
opinion so lightly. So, it might be worth at least a quick look? :-)
--
François Pinard http://pinard
elcome. Some priests do not know sex! :-)
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Guido van Rossum]
> On 7/7/05, François Pinard <[EMAIL PROTECTED]> wrote:
> > [Guido van Rossum]
> > > I even wonder if else-clauses on for/while were a good idea.
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
&
[Guido van Rossum]
> I even wonder if else-clauses on for/while were a good idea.
I surely find them useful, and see them as a Python originality (a
welcome one).
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Pyt
31 matches
Mail list logo
