"Public" Version control for Project Phoenix?

Is there, or do I, as I read under “Contributing,” just hack-and-send? If there is, does it include the wx.lib stuff?

DG

You can use the wxWidgets Trac:

http://trac.wxwidgets.org/

To submit your work, preferably as a patch against the existing SVN
copy of the module(s) you have been working on. If it belongs to
wx.lib, please set the "Component" tag to "wxPython and mention
"wx.lib" in the keywords text field.

Please remember that, if you have ported a module in wx.lib to Phoenix
(not a sample, a module), it will need to have proper docstrings and
unit test before the BDFL will accept to apply your patch. For the
documentation bit, please see here:

http://wiki.wxpython.org/ProjectPhoenix/DocumentationProject
http://wxpython.org/Phoenix/docs/html/DocstringsGuidelines.html

For a few examples of how to implement unit testing, see here:

http://svn.wxwidgets.org/viewvc/wx/wxPython/Phoenix/trunk/unittests/

···

On 12 July 2012 03:00, OlyDLG wrote:

Is there, or do I, as I read under "Contributing," just hack-and-send? If
there is, does it include the wx.lib stuff?

--
Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

Is there, or do I, as I read under "Contributing," just hack-and-send?

It's in the wxWidgets subversion repository, which anybody can read. https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/ As Andrea mentioned you can submit patches to Trac.

If there is, does it include the wx.lib stuff?

Not yet, but it will soon. Probably this evening. Since it won't be a simple branch (things are coming from multiple places, with some being excluded) I want to make sure it's done right. So I've been waiting until I have a good block of time to focus on it.

Please don't focus too hard on Py3 compatibility yet. I think there is still a decision or two to be made about which approach to take. As I wrote in the migration plan I really think that it will save some confusion if we do it in two phases. First Classic to Phoenix with Py2.7, and then Py3. I would also like to be sure that we have both versions in the source repository. In other words, first a commit that is Phoenix compatible, and then a commit that adds Py3 compatibility if needed. If there are simple (1 line) things you see along the way that will help make things 2/3 compatible without using a helper module then go ahead and do them, but it would be nice if the rest could wait a little longer.

http://wiki.wxpython.org/ProjectPhoenix/LibraryMigration

···

On 7/11/12 6:00 PM, OlyDLG wrote:

--
Robin Dunn
Software Craftsman

OK. On your final note: how have you been/do you want to handle the change in print syntax: using a “brute-force” if 3.X print(me) else print me approach, or something more elegant?

···

On Thursday, July 12, 2012 10:05:48 AM UTC-7, Robin Dunn wrote:

On 7/11/12 6:00 PM, OlyDLG wrote:

Is there, or do I, as I read under “Contributing,” just hack-and-send?

It’s in the wxWidgets subversion repository, which anybody can read.
https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/ As Andrea
mentioned you can submit patches to Trac.

If there is, does it include the wx.lib stuff?

Not yet, but it will soon. Probably this evening. Since it won’t be a
simple branch (things are coming from multiple places, with some being
excluded) I want to make sure it’s done right. So I’ve been waiting
until I have a good block of time to focus on it.

Please don’t focus too hard on Py3 compatibility yet. I think there is
still a decision or two to be made about which approach to take. As I
wrote in the migration plan I really think that it will save some
confusion if we do it in two phases. First Classic to Phoenix with
Py2.7, and then Py3. I would also like to be sure that we have both
versions in the source repository. In other words, first a commit that
is Phoenix compatible, and then a commit that adds Py3 compatibility if
needed. If there are simple (1 line) things you see along the way that
will help make things 2/3 compatible without using a helper module then
go ahead and do them, but it would be nice if the rest could wait a
little longer.

http://wiki.wxpython.org/ProjectPhoenix/LibraryMigration


Robin Dunn

Software Craftsman

http://wxPython.org

print(“Hello world!”) works in Python 2.x. :slight_smile: It just sees the argument as a one-element tuple.

···

On Jul 12, 2012, at 4:22 PM, OlyDLG wrote:

OK. On your final note: how have you been/do you want to handle the change in print syntax: using a “brute-force” if 3.X print(me) else print me approach, or something more elegant?

On Thursday, July 12, 2012 10:05:48 AM UTC-7, Robin Dunn wrote:

On 7/11/12 6:00 PM, OlyDLG wrote:

Is there, or do I, as I read under “Contributing,” just hack-and-send?

It’s in the wxWidgets subversion repository, which anybody can read.
https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/ As Andrea
mentioned you can submit patches to Trac.

If there is, does it include the wx.lib stuff?

Not yet, but it will soon. Probably this evening. Since it won’t be a
simple branch (things are coming from multiple places, with some being
excluded) I want to make sure it’s done right. So I’ve been waiting
until I have a good block of time to focus on it.

Please don’t focus too hard on Py3 compatibility yet. I think there is
still a decision or two to be made about which approach to take. As I
wrote in the migration plan I really think that it will save some
confusion if we do it in two phases. First Classic to Phoenix with
Py2.7, and then Py3. I would also like to be sure that we have both
versions in the source repository. In other words, first a commit that
is Phoenix compatible, and then a commit that adds Py3 compatibility if
needed. If there are simple (1 line) things you see along the way that
will help make things 2/3 compatible without using a helper module then
go ahead and do them, but it would be nice if the rest could wait a
little longer.

http://wiki.wxpython.org/ProjectPhoenix/LibraryMigration


Robin Dunn

Software Craftsman

http://wxPython.org

To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-dev?hl=en

Since it would be a SyntaxError in Py3 without the parens that won't work. The easiest thing to do is just add the parens and make sure that it is only one expression. Then in Py2 it ignores the parens because that is legal syntax for an expression.

So:

     print foo

becomes:

     print(foo)

and it works in both. If there is more than one expression being printed then you need to do something else like separate it into multiple prints, or do something like changing this:

     print foo, bar, spam, ham

into this:

     print("%s %s %s %s" % (foo, bar, spam, ham))

···

On 7/12/12 4:22 PM, OlyDLG wrote:

OK. On your final note: how have you been/do you want to handle the
change in print syntax: using a "brute-force" if 3.X print(me) else
print me approach, or something more elegant?

--
Robin Dunn
Software Craftsman

Oh, and if there is something that is just too difficult to convert like one of the examples above then you could always add a "from __future__ import print_function" at the top of the module.

···

On 7/12/12 4:53 PM, Robin Dunn wrote:

On 7/12/12 4:22 PM, OlyDLG wrote:

OK. On your final note: how have you been/do you want to handle the
change in print syntax: using a "brute-force" if 3.X print(me) else
print me approach, or something more elegant?

Since it would be a SyntaxError in Py3 without the parens that won't
work. The easiest thing to do is just add the parens and make sure that
it is only one expression. Then in Py2 it ignores the parens because
that is legal syntax for an expression.

So:

     print foo

becomes:

     print(foo)

and it works in both. If there is more than one expression being
printed then you need to do something else like separate it into
multiple prints, or do something like changing this:

     print foo, bar, spam, ham

into this:

     print("%s %s %s %s" % (foo, bar, spam, ham))

--
Robin Dunn
Software Craftsman

Not quite. If it had a , after the 2nd " then it would be a tuple. Without it then it is just an expression that evaluates to a string.

···

On 7/12/12 4:41 PM, Kevin Ollivier wrote:

print("Hello world!") works in Python 2.x. :slight_smile: It just sees the argument
as a one-element tuple.

--
Robin Dunn
Software Craftsman

Excellent “review,” thanks! (I’m sure that from future paradigm will be very handy in other contexts as well…)

···

On Thursday, July 12, 2012 4:57:31 PM UTC-7, Robin Dunn wrote:

On 7/12/12 4:41 PM, Kevin Ollivier wrote:

print(“Hello world!”) works in Python 2.x. :slight_smile: It just sees the argument

as a one-element tuple.

Not quite. If it had a , after the 2nd " then it would be a tuple.
Without it then it is just an expression that evaluates to a string.


Robin Dunn

Software Craftsman

http://wxPython.org