> For comparison, the revival of the "u" string prefix in Py3.3 is a simple
> change in the parser grammar that's easy to maintain but that has a huge
> impact on the Py3 compatibility of code that accepts to drop support for
> Py2.5 and earlier (as well as Py3.[012]) but wants to keep working in
> Py2.[67] (which supports the opposite "b" prefix).
And even this simple change has caused unexpected issues (see issues #15054 and #15096), which were not predicted by the preceding stormy discussion. IMHO, the negative consequences of this change are undervalued.
> On 27.06.12 14:22, Stefan Behnel wrote:
>> For comparison, the revival of the "u" string prefix in Py3.3 is a simple
>> change in the parser grammar that's easy to maintain
> And even this simple change has caused unexpected issues (see issues
> #15054 and #15096), which were not predicted by the preceding stormy
> discussion.
#15054 was mostly not about 'u'.
http://bugs.python.org/issue15096 is about 'u', or rather about the post discussion extension of 'u' to 'ur'. During the discussion of 'u', I predicted that adding 'innocuous' 'u' would lead to efforts to add other things. Adding 'ur' was the first example of that. We are fortunate that someone decided to test the new feature at the alpha stage. At least the near fiasco is a lesson.
> IMHO, the negative consequences of this change are undervalued.
Another prediction: people who code Python without reading the manual, at least not for new features, will learn about 'u' somehow (such as by reading this list) and may do either of the following, both of which are bad.
1. They will confuse themselves by thinking that 'u' actually means somethings. They may then confuse others by writing about its supposed meaning. This might get amusing.
2. They will use 'u' in Python 3 only code, thereby making it incompatible with 3.2-, even if it otherwise would not be.
On Jun 28, 8:11 am, Christian Tismer <tis...@stackless.com> wrote:
> Random notes without context and reasoning are no better than spam.
> My answer as well, of course, so let's stop here.
It's more that all of this has been discussed at length. Repeatedly.
It's very easy to criticise the current state of affairs when you
didn't actively participate in the lead up to it and, by your own
admission, really just want tools to "abuse" existing libraries
without putting effort into migration. It's fine that you want this,
but don't expect anyone else to put in effort where you're not
prepared.
If you believe providing a complementary __past__ namespace will work
- even though I believe Guido has explicitly stated it will never
happen - then the onus is on you to come up with an implementation.
On Monday, June 25, 2012 10:35:14 PM UTC-5, Steven D'Aprano wrote:
> (Rick, don't make me regret communicating with you again.)
Well unfortunately Steven i am not sure what causes you to stop communicating with me for these seeming random periods of time -- although i can deduce from past experiences that you have difficulty accepting diverse opinions, then, your emotions take control causing you to wield the only weapon of recourse you have available to you: the kill file -- so in that sense, i cannot provide a solution for a problem that exists beyond my control. HTH.
> On Mon, 25 Jun 2012 19:28:01 -0700, rantingrickjohnson wrote:
> There's no real difference between typing print(...) and all the other > functions in Python. Do you lament having to type len(obj) instead of > "len obj" or list(zip(a, b, c)) instead of "list zip a b c"?
No. I actually like the forced parenthesis -- even when on a function declaration with no arguments. I think this is a consistent approach. And boy do i love consistency!
> Making print a statement in the first place was a mistake, but > fortunately it was a simple enough mistake to rectify once the need for > backward compatibility was relaxed.
Agreed. However, my comment was not a rant against the new print function, more that, it is a warning against pushing people to learn Python 2.x FIRST, and therby "training" them with the bad habit of using a "naked print syntax" that they will surely lament in the future.
For me the print statement is like a big old delicious chocolate chip cookie and the print function is like a plate of leafy vegetables. I know i should eat my vegetables; but that damn cookie is just too tempting!
On Tuesday, June 26, 2012 1:24:43 AM UTC-5, Stefan Behnel wrote:
> Maybe we should add a remote error reporting mode to Python that sends all
> syntax error messages not only to the local screen but also directly to the
> PSF so that they can fund developers who are able to delete that error
> message from the interpreter based on real world statistical evidence. That
> would eventually make the language match the powerset of what all users
> have in their fingers. A very worthy goal, if you ask me.
I'm sure you meant this a joke, however, some feedback like this would be greatly beneficial to the developers and community. It's not something you'd want to send each time an exception is thrown, but a log could be requested for delivery from time to time. I think it would be a great addition to any python editor; especially those geared toward neophytes: like IDLE and such.
On Tuesday, June 26, 2012 1:24:43 AM UTC-5, Stefan Behnel wrote:
> Maybe we should add a remote error reporting mode to Python that sends all
> syntax error messages not only to the local screen but also directly to the
> PSF so that they can fund developers who are able to delete that error
> message from the interpreter based on real world statistical evidence. That
> would eventually make the language match the powerset of what all users
> have in their fingers. A very worthy goal, if you ask me.
I'm sure you meant this a joke, however, some feedback like this would be greatly beneficial to the developers and community. It's not something you'd want to send each time an exception is thrown, but a log could be requested for delivery from time to time. I think it would be a great addition to any python editor; especially those geared toward neophytes: like IDLE and such.
On Tuesday, June 26, 2012 1:34:03 AM UTC-5, Stefan Behnel wrote:
> First of all, the statement has a rather special syntax that is not obvious
> and practically non-extensible. It also has hidden semantics that are hard
> to explain and mixes formatting with output - soft-space, anyone?
> The function is straight forward, configurable, does one thing, works with
> help() and doesn't get in the way. And something as rarely[1] used as a
> print simply doesn't deserve special syntax. Oh, and, yes, you can even
> pass it into some code as callback, although I rarely had a need for that.
> Stefan
> [1] Seriously, it's not very helpful in interactive mode and too simplistic
> to be used in application code. Even scripts often work better with logging
> than with prints.
Unfortunately, even though "print" is supposedly only used by the neophytes, the python<3.0 stdlib is full of print statements. For instance, out of 3173 files, 986 contained the word "print"[1]. Heck just in the Lib folder alone (without recusing down sub directories) there are 1352 instances of "print" in a "py" file!
Naive Nancy Mused: "If only neophtes use print, and the Python Lib is full of prints statements, then the python developers must be...OH DEAR GAWD!"
[1] of course that is when using `filestr.count("print")` -- I assume that the word "print" is not used excessively in comments or docstrings. Someone else can do a less naive search if they like.
On Tuesday, June 26, 2012 1:34:03 AM UTC-5, Stefan Behnel wrote:
> First of all, the statement has a rather special syntax that is not obvious
> and practically non-extensible. It also has hidden semantics that are hard
> to explain and mixes formatting with output - soft-space, anyone?
> The function is straight forward, configurable, does one thing, works with
> help() and doesn't get in the way. And something as rarely[1] used as a
> print simply doesn't deserve special syntax. Oh, and, yes, you can even
> pass it into some code as callback, although I rarely had a need for that.
> Stefan
> [1] Seriously, it's not very helpful in interactive mode and too simplistic
> to be used in application code. Even scripts often work better with logging
> than with prints.
Unfortunately, even though "print" is supposedly only used by the neophytes, the python<3.0 stdlib is full of print statements. For instance, out of 3173 files, 986 contained the word "print"[1]. Heck just in the Lib folder alone (without recusing down sub directories) there are 1352 instances of "print" in a "py" file!
Naive Nancy Mused: "If only neophtes use print, and the Python Lib is full of prints statements, then the python developers must be...OH DEAR GAWD!"
[1] of course that is when using `filestr.count("print")` -- I assume that the word "print" is not used excessively in comments or docstrings. Someone else can do a less naive search if they like.
Rick, fix your mail reader/sender, your lines aren't wrapping
properly.
On Jun 28, 1:53 pm, rantingrickjohn...@gmail.com wrote:
> Unfortunately, even though "print" is supposedly only used by the neophytes, the python<3.0 stdlib is full of print statements. For instance, out of 3173 files, 986 contained the word "print"[1]. Heck just in the Lib folder alone (without recusing down sub directories) there are 1352 instances of "print" in a "py" file!
Stefan said "rarely used". Until you count all keywords & built-ins in
those files and provide a relative basis of comparison, you're not
saying anything here.
> Naive Nancy Mused: "If only neophtes use print, and the Python Lib is full of prints statements, then the python developers must be...OH DEAR GAWD!"
It's a good thing there's no open flame around given the sheer number
of strawmen you stuff into your posts.
No one made any such claim about "neophytes", just that logging can be
better than print() as a general debugging tool.
> [1] of course that is when using `filestr.count("print")` -- I assume that the word "print" is not used excessively in comments or docstrings. Someone else can do a less naive search if they like.
So you couldn't even be bothered to do it right, but you're happy to
form a noisy opinion on this crap, and now the onus is on someone else
to correct the ignorance you've pushed onto this list. Again.
On Wed, 27 Jun 2012 17:44:23 -0700, alex23 wrote:
> If you believe providing a complementary __past__ namespace will work -
> even though I believe Guido has explicitly stated it will never happen -
> then the onus is on you to come up with an implementation.
Guido speaks only for CPython. Other implementations can always do differently.
The Python 3 naysayers are welcome to fork Python 2.7 and support it forever, with or without a __past__ namespace. That's the power of open source software.
And who knows, if it becomes popular enough, perhaps it will be ported to CPython too.
> Another prediction: people who code Python without reading the manual,
> at least not for new features, will learn about 'u' somehow (such as by
> reading this list) and may do either of the following, both of which are
> bad.
> 1. They will confuse themselves by thinking that 'u' actually means
> somethings. They may then confuse others by writing about its supposed
> meaning. This might get amusing.
> 2. They will use 'u' in Python 3 only code, thereby making it
> incompatible with 3.2-, even if it otherwise would not be.
> These two actions will reinforce each other.
Yes, this is what I mean. I can even make a prediction: in just 5 years, as this feature would be banned in a decent society. The authors of the books will be strongly advise not to use it, and in software companies 'u' will be prohibited in coding style. But get rid of this will be difficult.
> On 28.06.12 00:14, Terry Reedy wrote:
>> Another prediction: people who code Python without reading the manual,
>> at least not for new features, will learn about 'u' somehow (such as by
>> reading this list) and may do either of the following, both of which are
>> bad.
>> 1. They will confuse themselves by thinking that 'u' actually means
>> somethings. They may then confuse others by writing about its supposed
>> meaning. This might get amusing.
>> 2. They will use 'u' in Python 3 only code, thereby making it
>> incompatible with 3.2-, even if it otherwise would not be.
>> These two actions will reinforce each other.
> Yes, this is what I mean. I can even make a prediction: in just 5 years, as
> this feature would be banned in a decent society. The authors of the books
> will be strongly advise not to use it, and in software companies 'u' will
> be prohibited in coding style. But get rid of this will be difficult.
Once Py2.7 is out of maintenance, we can deprecate that feature in one
release and start warning about it in the next one. You're then free to use
the corresponding 2to3 fixer to get it back out of your code with a single
patch.
On Thursday, June 28, 2012 7:47:24 AM UTC+2, Stefan Behnel wrote:
> Serhiy Storchaka, 28.06.2012 07:36:
> > On 28.06.12 00:14, Terry Reedy wrote:
> >> Another prediction: people who code Python without reading the manual,
> >> at least not for new features, will learn about 'u' somehow (such as by
> >> reading this list) and may do either of the following, both of which are
> >> bad.
> >> 1. They will confuse themselves by thinking that 'u' actually means
> >> somethings. They may then confuse others by writing about its supposed
> >> meaning. This might get amusing.
> >> 2. They will use 'u' in Python 3 only code, thereby making it
> >> incompatible with 3.2-, even if it otherwise would not be.
> >> These two actions will reinforce each other.
> > Yes, this is what I mean. I can even make a prediction: in just 5 years, as
> > this feature would be banned in a decent society. The authors of the books
> > will be strongly advise not to use it, and in software companies 'u' will
> > be prohibited in coding style. But get rid of this will be difficult.
> Once Py2.7 is out of maintenance, we can deprecate that feature in one
> release and start warning about it in the next one. You're then free to use
> the corresponding 2to3 fixer to get it back out of your code with a single
> patch.
> Stefan
On the other side, one can argue this (elegancy):
b'a serie of bytes'
u'a unicode, a serie of code points'
On Thursday, June 28, 2012 7:47:24 AM UTC+2, Stefan Behnel wrote:
> Serhiy Storchaka, 28.06.2012 07:36:
> > On 28.06.12 00:14, Terry Reedy wrote:
> >> Another prediction: people who code Python without reading the manual,
> >> at least not for new features, will learn about 'u' somehow (such as by
> >> reading this list) and may do either of the following, both of which are
> >> bad.
> >> 1. They will confuse themselves by thinking that 'u' actually means
> >> somethings. They may then confuse others by writing about its supposed
> >> meaning. This might get amusing.
> >> 2. They will use 'u' in Python 3 only code, thereby making it
> >> incompatible with 3.2-, even if it otherwise would not be.
> >> These two actions will reinforce each other.
> > Yes, this is what I mean. I can even make a prediction: in just 5 years, as
> > this feature would be banned in a decent society. The authors of the books
> > will be strongly advise not to use it, and in software companies 'u' will
> > be prohibited in coding style. But get rid of this will be difficult.
> Once Py2.7 is out of maintenance, we can deprecate that feature in one
> release and start warning about it in the next one. You're then free to use
> the corresponding 2to3 fixer to get it back out of your code with a single
> patch.
> Stefan
On the other side, one can argue this (elegancy):
b'a serie of bytes'
u'a unicode, a serie of code points'
On Thu, Jun 28, 2012 at 7:34 PM, <wxjmfa...@gmail.com> wrote:
> On the other side, one can argue this (elegancy):
> b'a series of bytes'
> u'a unicode, a series of code points'
Alas, not perfectly so. A 'bytes' object and a 'unicode' object can be
described that way (with 'str' an alias for one or t'other), but
literal strings are never that simple. (Backslash escapes, delimiters,
newlines, etc, etc, etc.) However, it is a nice idea, to the extent
that it's possible.
