I've written about 100,000 lines of Py3K code since it
was released, mostly on evenings and weekends, so I
was very excited to see Van release the new 3to2 tool
today.
I immediately ran it against my codebase, and it
mostly works, but I got some strange diagnostics:
line 673234: lambda cannot
--- Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Steve Howell yahoo.com> writes:
> >
> >line 673234: lambda cannot be renamed in ANY
> > temporal dimension
> >
> [...]
> >
> >line 913975: parens not removed from print(),
> >
Hi, this is my first post to the list. My name is
Steve Howell, and I currently work on a system,
largely written in Python, that processes a billion
transactions per year. On the opposite side of the
sprectrum, I've also had experience in classrooms
using Python as a teaching tool.
I
--- Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 5/22/07, Steve Howell <[EMAIL PROTECTED]>
> wrote:
> >
> > In the system I've worked on for the last three
> years,
> > we have at least 200 calls to the builtin open()
> > method.
>
> T
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Steve Howell <[EMAIL PROTECTED]>
> wrote:
> > 17.7% of the files I searched have calls to
> open().
>
> My understand is that the mythical "python 2.x ->
> 3.0" tool will
> automa
--- Georg Brandl <[EMAIL PROTECTED]> wrote:
> ISTM that many modules using open() do also use
> os.path
> utilities to create the filename given to open(). In
> that
> case, you have an import statement in any case.
>
Not the case for us:
154 modules call only open()
11 modules call only o
--- Neil Toronto <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Thank you for hitting home that unless people use
> Emacs, their tools
> > arent sufficient for Python development. I still
> don't believe that my
> > concerns have been addressed. And I certainly
> don't believe that those
--- Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> In summary, my preference ordering of the
> possibilities would be:
>
> [...]
>
> 2. "python" allows only ASCII identifiers.
> "python -U" allows
> Unicode identifiers that are in NFC and use
> a conservative,
> *fixed* subset of
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Regarding using looking-alike glyphs (in certain
> fonts) security
> issues, wouldn't it be a good thing for any project
> anyway to have a
> number of pre-conditions for any given contribution
> to a given project
> to be cleared. On of such litmu
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [...]
> > 2. "python" allows only ASCII identifiers.
> "python -U" allows
> > Unicode identifiers that are in NFC and
> use a conservative,
> > *fixed* subset of the available
> characters. Support for
> > "-U" is a
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> I'd make it more tedious and more flexible to relax
> the restriction,
> actually. "python" gives you the stdlib, ASCII-only
> restriction.
> "python -U TABLE" takes a mandatory argument, which
> is the table of
> allowed characters.
Now
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > FWIW the Ruby interpreter (1.8.5) seems to require
> > this flag to allow you to turn on the Japanese
> code
> > set.
> >
> > -Kkcode specifies KANJI (Japanese) code-set
> >
> > I have no idea whether or not this cripples the
> > feature i
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> -2. Any solution found must also accommodate users
> which are unaware
> of the security issue, and just want to use their
> native language
> for identifiers. So requiring them to change their
> environment or
> pass additional command line pa
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
>
> The additional burden that ascii loving people would
> like to impose on
> the rest of the world through the usage of command
> line switches is
> unwanted IMHO.
>
I think now that PEP 3131 has been accepted, you can
coarsely frame the remainin
--- Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Steve Howell wrote:
> > I think now that PEP 3131 has been accepted, you
> can coarsely frame
> > the remaining conflict as between ascii lovers and
> non-ascii lovers
>
> To pit this as "ascii lovers vs.
--- Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If there's a security argument to be made for
> restricting the alphabet
> used by code contributions (even by co-workers at
> the same company), I
> don't see why ASCII-only projects should have it
> easier than projects
> in other cultures.
>
>
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> Steve Howell writes:
>
> > respect to Kanji, and switches over to Python,
> and
> > changes his little wrapper shell script to say
> "python
> > -U" instead of "ruby -Kk
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > In almost every programming situation I've been
> in,
> > I've had to deal with environmental issues, even
> > though my character set of choice has never been
> the
> > primary issue.
>
> People can certainly adjust to whatever challenges
> t
--- Guillaume Proux <[EMAIL PROTECTED]> wrote:
> If you look at the typical use case for programs
> written in python
> (usually also in rough order of experience)
> A) directly in interpreter (i love that)
> B) small-ish one-off scripts
> C) middle size scripts
> D) multi-module programs made by
--- Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 5/24/07, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >
> > > It doesn't look like any kind of global flag
> passed to the interpreter
> > > would scale -- once I am using a known trusted
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Baptiste Carvello, in addition to Jim, Ka-Ping,
> Stephen, and myself,
> further discusses why ascii is the only sane default
> in his most recent
> 3 posts.
I will add my much less venerated name to the list of
people who think ascii is the san
--- Steve Howell <[EMAIL PROTECTED]> wrote:
> --- Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > On 5/25/07, Jim Jewett <[EMAIL PROTECTED]>
> wrote:
> > > On 5/24/07, Guido van Rossum <[EMAIL PROTECTED]>
> > wrote:
> > >
> &g
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> By the way, this is an example that shows that the
> recent injection of
> the word "parochial" is truly pernicious, because
> it's attached to the
> wrong set of arguments.
>
Sorry. I'm one of the folks who has propagated that
term, and
--- Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> However, this does not
> matter for teaching and for in-house code, which are
> the most compelling use
> cases of the new feature.
>
For the teaching use case, I'm wondering if the
English keywords would already present too high a
barrier for s
Here is a survey of some Python code to see how often
tokens typically get used in Python 2.
Here is the program I used to count the tokens, if you
want to try it out on your own in-house codebase:
import tokenize
import sys
fn = sys.argv[1]
g = tokenize.generate_tokens(open(fn).readline)
dct = {
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Perhaps, but there is a growing contingent here that
> are of the opposite
> opinion. And even though this contingent is of
> differing opinions on
> whether unicode identifiers should even be allowed,
> we all agree that if
> they are allowed, t
There has been a lot of interesting debate about PEP
3131, but I think some perspective could be brought to
the table by showing actual code examples.
Can somebody post a few examples of what Python code
would look like under PEP 3131? Maybe 10-to-15 line
programs that illustrate the following us
--- BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> > Those most eager for unicode identifiers are
> afraid that people
> > (particularly beginning students) won't be able to
> use local-script
> > identifiers, unless it is the default. My feeling
> is that the teacher
> > (or the person who pointe
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> # Definition von Element sei gegeben
>
> class Liste:
> def __init__(self):
> self.erstes_element = None
>
> def einfügen(self, objekt):
> if not self.erstes_element:
> self.erstes_element = Element(objekt)
> else:
>
--- Michael Urman <[EMAIL PROTECTED]> wrote:
>
> The arguments then feel reduced to "Unicode enhances
> readability" vs.
> "Unicode impedes readability" and since clearly it
> does both, how do
> we make the value judgement about which it does
> more? How do we weigh
> the ability to use native l
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Here is some code borrowed right from the Python
> standard library. I've
> gone ahead and mangled names in a consistant fashion
> using the tokenize
> module. Can you guess what it does?
>
>
> class RTrCOlOrB :
>
> nBBjIUrB =0
>
> def
--- Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steve Howell wrote:
> > the one word that I wasn't able to
> > translate, even with the help of Babelfish, was
> the
> > German word for "insert." It turns out the thing
> that
> > threw me
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > I hate to make a decision by majority rule, but I
> > think there is the argument that you need to weigh
> the
> > population of ascii-literate people vs.
> > ascii-illiterate people.
>
> That's a very poor criteria, as not everyone in the
> w
--- Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> > > B. Should the default behaviour accept only
> ASCII identifiers, or
> > >should it accept identifiers containing
> non-ASCII characters?
> >
> > Added as an open issue.
> [...]
Martin, I hope you close out this issue, and just make
a firm,
--- Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> Ideally, either that equivalence would also include
> compatibility, or
> else characters whose compatibility and canonical
> equivalents are
> different would be banned for use in identifiers.
>
Current Python has the precedence that color/colour
a
--- Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf
> (Conformance)
> >
> > C9 A process shall not assume that the
> interpretations of two
> > canonical-equivalent character sequences are
> distinct.
>
> That is surely contained inside all sort
--- James Y Knight <[EMAIL PROTECTED]> wrote:
>
> I'm pretty sure the answer is still going to
> be the second: I'd
> rather a program written in Chinese use Chinese
> characters, rather
> than a transliteration of Chinese into ASCII.
> because it is actually
> feasible for me to do automat
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I think this whole debate could be put to rest by
> > agreeing to err on the side of ascii in 3.0 beta,
> and
> > if in real world experience, that turns out to be
> the
> > wrong decision, simply fix it in 3.0 production,
> 3.1,
> > or 3.2.
>
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Unfortunately, teachers don't participate
> in python-3000, as don't many other Python users.
> So it's unlikely that you find a teacher posting
> *here*, it was pure luck that I found a Chinese
> teacher posting on comp.lang.python. You would
>
--- Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> Leonardo Santagada a écrit :
> > I don't. It is a bad idea to distribute non-ASCII
> code for libraries
> > that are supposed to be used by the world as a
> whole. But
> > distributing a chinese code for doing something
> like taxes using
>
--- "Stephen J. Turnbull" <[EMAIL PROTECTED]>
wrote:
> Ka-Ping Yee writes:
> > Both of these come down to the wastefulness of
> redoing something
> > that the Python interpreter itself already knows
> how to do very
> > well, and is, in some sense by definition, the
> authority on how
> > to d
--- Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>
> si tu me prends par les sentiments :-) Really, you
> make it sound so nice I would
> almost change my mind. Still wondering how much of
> an effort it will be, though.
>
I would again make a call out for actual examples of
what Python code w
--- Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/12/07, Steve Howell <[EMAIL PROTECTED]>
> wrote:
>
> > In my best franglais: je pense que les avocats de
> PEP
> > 3131 pourrait surmonter la doute, l'incertitude,
> le
> > crainte, etc., de PEP 31
+1 on deciding on keeping builtins built in based on
populuarity within actual source code.
Stats will never be perfect, and nobody can
practically sample all Python code ever written, but
anybody who measures a large codebase to argue for
keeping a builtin built in gets a +1 from me.
Regarding m
--- Bill Janssen <[EMAIL PROTECTED]> wrote:
> [...] It's more important to make things work
> consistently than to only
> have "one way". "sum" should concatenate strings.
>
"Sum" should sum stuff. You can't sum strings. It
makes no sense in English.
You can concatenate strings, or you can
--- Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Multiple additions (with "+") mean "sum" in
> > arithmetic, but you can't generalize that to
> strings
> > and text processing. The "+" operator for any two
> > strings is not about adding--it's about
> > joining/concatenating. So multiple applica
--- Andrew McNabb <[EMAIL PROTECTED]> wrote:
>
> I think you're technically right, but I frequently
> find myself using the
> phrase "add together a list of strings" when it
> would be more accurate
> to say "concatenate a list of strings." I can't say
> I feel bad when I
> use this terminology
--- Bill Janssen <[EMAIL PROTECTED]> wrote:
> > My other concern with sum() is just the common
> pitfall
> > that you do sum(line_of_numbers.split(',')) and
> get
> > '35' when you intended to write code to get 8.
> I'd
> > rather have that fail obviously than subtlely.
>
> Common pitfall? I
--- Andrew McNabb <[EMAIL PROTECTED]> wrote:
>
> I agree that on its own, it's not the most natural
> method. However,
> once you've already used the + operator to join two
> strings, you are
> much more likely to consider sum() for concatenating
> a list of strings.
> I remember being confused
--- Ron Adam <[EMAIL PROTECTED]> wrote:
>
>
> Bill Janssen wrote:
> >> I think you were missing my point, which is that
> sum
> >> doesn't and shouldn't necessarily have the same
> >> semantics as map(+).
> >
> > It's not that I don't understand your argument,
> Steve.
> >
> > I just don't fi
--- Greg Ewing <[EMAIL PROTECTED]> wrote:
> The word "add" has a wider connotation in English
> than
> "sum". [...]
Just to elaborate on the point...
And, likewise, symbolic operators have a wider
connotation in programming languages than do keywords.
Keywords can, and should, be more specifica
51 matches
Mail list logo
