Yes, but that is just one example. I'm pretty sure I ran into one or two other things that were SyntaxErrors in one or the other Python flavor when I was porting the build tools and the unittests, although I don't remember exactly what they were. I was able to find workarounds for those cases however, (which is why I don't remember them I suppose.)
···
On 5/31/12 8:59 AM, Chris Barker wrote:
On Wed, May 30, 2012 at 5:13 PM, Robin Dunn<robin@alldunn.com> wrote:
On 5/29/12 5:03 PM, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
For
example, using the u prefix on string constants (such as u"some text")
is a syntax error in Python 3.2.
And it looks like u"" will be coming back in Python 3.3... It doesn't
actually do anything of course, other than not issue a SyntaxError
exception.
Which is what it should always have been. There was no point at the
start in removing the 'u' prefix. I wonder how many developers have
had to refactor their code to deal with this nonsense, and I can
imagine GUI frameworks were hit the most. We now get it back.
Funny situation though, for wx.lib and Editra and the other 3rd party
packages with a lot, *a lot* of unicode literals in them. Do we keep
them there and support Python 2.7 and 3.3+ (thus excluding 3.0, 3.1
and 3.2) or do we do something else?
That's a bit of a pity. I got Phoenix built with PortablePython 3.2
but I am not going to touch AGW if we can keep the 'u' stuff in. I'll
just wait for PortablePython 3.3 and for a (possibly) final decision
on what Python versions we are going to support.
On Thu, May 31, 2012 at 10:59 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, May 30, 2012 at 5:13 PM, Robin Dunn <robin@alldunn.com> wrote:
On 5/29/12 5:03 PM, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
For
example, using the u prefix on string constants (such as u"some text")
is a syntax error in Python 3.2.
And it looks like u"" will be coming back in Python 3.3... It doesn't
actually do anything of course, other than not issue a SyntaxError
exception.
and couldn't we use:
from __future__ import unicode_literals
in 2.7 anyway?
Yes, if one wants to go through hundreds of thousands of lines of code
and remove the 'u' prefix from all strings using it. 3.3 sounds like
it will just ignore the 'u' so now instead of a syntax error it will
just be a regular unicode literal again.
Yes, if one wants to go through hundreds of thousands of lines of code
and remove the 'u' prefix from all strings using it. 3.3 sounds like
it will just ignore the 'u' so now instead of a syntax error it will
just be a regular unicode literal again.
I agree that this is a good change, but at least removing the "u" is
automatable. (presumably 2to3 does it as well)
Andrea wrote:
Do we keep
them there and support Python 2.7 and 3.3+ (thus excluding 3.0, 3.1
and 3.2) or do we do something else?
good point -- this _may_ be a reason to use the "from __future__
import unicode_literals" option, but as Robin mentions, unicode
literals are only one issue.
I imagine that in general 3.* users are more active an bleeding edge,
and thus supporting only 3.3+ may be OK. An by definition, anyone
going to 3.* with wxPython is new to 3.* anyway (at least for the GUI
portion of the code)
It is odd that the 'u' wasn't ignored in the first place. oh well.
-Chris
···
On Thu, May 31, 2012 at 9:51 AM, Cody <codyprecord@gmail.com> wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
I don't remember for sure but I think it was left in (and ignored) in 3.0 and 3.1, but was then removed in 3.2 assuming that nobody needed it any more.
···
On 5/31/12 1:45 PM, Chris Barker wrote:
It is odd that the 'u' wasn't ignored in the first place. oh well.
I thought _core was for essentially “native” widgets and _adv was for non-native widgets?
Personally I’d love to see some note in the new web-docs of which widgets are native to which OSes.
like line “Native widget: MSWXP+, MacOS10+” etc.
For apps (like basic admin tools) that use only native widgets is certain a memory saver, as basically the wx core would mostly be Python signatures to operating system calls and generic initialization code no? TO me I’d expect _adv and non-_core to be groupings of native widgets into a new-non-native widget;
To me however I’d organize the code into “native”, “common” and “advanced”. Where common widgets are not native but are used “commonly” and where advanced widgets would be something used often only in certain kinds of “apps like calendar widgets”. To me this structure also lends itself to easier maintainability.
···
On Friday, May 25, 2012 6:31:22 PM UTC-4, Robin Dunn wrote:
Andrea, I noticed that classes and functions from the wx.adv module are showing
up in the main part of the docs as ClassName instead of in a adv section
like what is happening for dataview. – Robin Dunn
well, python wrappers of C++ wrappers to OS calls -- not sure how big
those are, but maybe not so small (though smaller than a fully
wx-implemented widget, to be sure)
But it's nice to know what's a native widget and what's not in any case.
-Chris
···
On Fri, Jun 1, 2012 at 7:14 AM, DevPlayer <devplayer@gmail.com> wrote:
Personally I'd love to see some note in the new web-docs of which widgets
are native to which OSes.
like line "Native widget: MSWXP+, MacOS10+" etc.
For apps (like basic admin tools) that use only native widgets is certain a
memory saver, as basically the wx core would mostly be Python signatures to
operating system calls and generic initialization code no?
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception