Re: [Python-Dev] pydoc for named tuples is missing methods

[Eric Smith]

On 03/14/2011 10:02 PM, James Mills wrote:

On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy  wrote:

How would that work if you had a field named "replace"? I think
Raymond's current design is as good as it's going to get.


'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
the '_' from '_replace'. No gain. I might prefer _asdict to _as_dict, but
not enough to change.


Probably a stupid idea (sorry) but one could just
make asdict() and replace() public methods
with the caveat that developers not use those
as field names.


The field names are not always under direct control of the developer, 
such as when they are database column names. Not that using _replace 
completely gets rid of this problem, but I agree with Raymond's decision 
that a field name can be any valid identifier not starting with an 
underscore. It's the simplest thing for the developer using namedtuple.


Eric.

___
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

Re: [Python-Dev] packaging

[Nick Coghlan]

On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
 wrote:
> Maybe this will be the killer app for the "or" enhancement
> to the import statement. :-)

Except that won't help, since even if it were added right now, pre-3.3
compatible code couldn't use it :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Nick Coghlan]

On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith  wrote:
> The field names are not always under direct control of the developer, such
> as when they are database column names. Not that using _replace completely
> gets rid of this problem, but I agree with Raymond's decision that a field
> name can be any valid identifier not starting with an underscore. It's the
> simplest thing for the developer using namedtuple.

While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore to the
*end* (as_dict_, replace_, make_) as is sometimes done for code that
needs to avoid conflicting with a keyword.

Namespace collisions with actual fields would remain unlikely, while
pydoc would pick up the new names correctly.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Martin v. Löwis]

> In fact, since the deprecation in the Python 2 line happened in 2.7,
> the deprecation period of this API in practice was between July 3rd
> 2010 and February 20 2011. That is a deprecation period of somewhat
> longer than seven months. Nobody obviously though 2.6 was out of
> practical use by now, so why did you decide to remove one if it's
> API's?

Python 2.6's API wasn't removed in 2.7. It remains available.

If you go from 2.7 to 3.2, you should expect things to break. That's
why the major version changed.

For 3.x, as Reid points out, the API was deprecated in 3.1, so the
deprecation period was rather 19 months, not 7.

> Let's make no bones about this: The PyCObject API should *not* have
> been removed in 3.2. In fact, the removal should be reversed, and
> 3.2.1 should be released ASAP, making 3.2 a moot and unsupported
> version.

This change conforms to PEP 5:

"There must be at least a one-year transition period between the
release of the transitional version of Python and the release
of the backwards incompatible version.  Users will have at
least a year to test their programs and migrate them from use
of the deprecated construct to the alternative one."

If you think a year is too little, you should lobby for a PEP 5
change.

Regards,
Martin

___
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

Re: [Python-Dev] NetBSD and curses

[Gregory P. Smith]

Would you please post this to bugs.python.org so that it doesn't get lost?
 thanks!

-gps

On Mon, Mar 14, 2011 at 8:51 PM, Bill Green  wrote:

> Hi all,
>
> I ran across this issue several months ago and filed a bug report (#9667).
>  It just came up again, and it doesn't look like anything's been done with
> the bug report, so I thought I'd post here.
>
> In _cursesmodule.c there are a lot of preprocesser conditionals that test
> if the system is NetBSD. In my case, the issue was that the module built
> lacked the KEY_UP / _DOWN / etc. constants, but there are other changes as
> well.  This is the case even if you're compiling against ncurses instead of
> the system curses.  Αttached below is a patch against 2.7.1 that negates the
> NetBSD conditionals if ncurses is present.  It seems to work as expected,
> although I haven't done any real testing.  I assumed this was done because
> NetBSD curses was missing something, but I looked at the headers and it
> seems to have most of the constants that the compilation directives are
> leaving out (A_INVIS, the aforementioned KEY_* constants, at least), so I'm
> not sure why that code isn't compiled in anyway.  Please let me know if I'm
> misunderstanding this.
>
> Thanks,
> Bill
>
> ___
> 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/greg%40krypto.org
>
>
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Tim Lesher]

On Mon, Mar 14, 2011 at 08:28, Tim Lesher  wrote:
> On Mon, Mar 14, 2011 at 05:45, Nick Coghlan  wrote:
>> There are two relatively simple ways forward I can see:
>>
>> A. Add a __public__ attribute that pydoc (and import *) understand.
>> This would overrride the default "this is private" detection and add
>> affected names to the public list (without needing to respecify all
>> the "default public" names - this is important in order to support
>> subclassing correctly)
>
> I believe this was the direction the bug report was implying.
>
> I'll be sprinting for a few hours this morning; if there are no
> objections, I will try to turn this idea into a patch that makes
> pydoc.visiblename look for a __public__ function attribute as "step
> 0".
>
> Maybe there should also be a @public decorator to apply it, although
> that name may be an attractive nuisance, tempting C++ or Java
> programmers new to Python to ask for @protected and @private...

I implemented this on Monday, and it worked great... for instance
methods.  Unfortunately, it doesn't do a thing for classmethods or
data attributes, which are 2/4 of the original namedtuple use cases,
so it feels like a bad idea.

In the process of implementing it, though, I realized that the __all__
mechanism for modules could still be reused.  Two implementations came
to mind:

1. Allow an __all__ class attribute that affects pydoc for classes the
same way it does for modules.
Pro: it's familiar, easy to explain, and easy to implement (four lines of code)
Con: the original use case (adding a small number of
otherwise-excluded attributes to existing documentation) is
cumbersome. Because __all__ means "don't document anything but
__special_names__ and the contents of __all__, you'd have to manually
add names that pydoc would normally pick up.  Also, __all__ itself
will show up in the documentation, which seems to me like useless
clutter to a reader of help().

2. Add a new class attribute that uses the same mechanism, with a
different name (e.g., __api__).
Pro: fairly easy to explain; because it doesn't share a name with
__all__ its semantics can be tweaked without confusing people.
Con: slight additional cognitive burden of a new feature

I'm implementing both of these separately this week to see which works
better in practice.  So far I'm liking __api__ better, with these
semantics:

1. Classes without __api__ are treated just as they are today.
2. __api__ on classes works just like __all__ on modules (only special
names, plus its contents are documented)
3. Additionally, __api__ can take an Ellipsis.  That makes the __api__
list additive--pydoc documents everything it normally would, *plus*
the contents of __api__
4. __api__ is added to pydoc's "hidden names" list; since its only
purpose is to help generate docs, its value would be of little use in
the generated docs themselves.

Point 3 (Ellipsis) is unusual, but to me it makes the declaration read
well and solves the namedtuple case succinctly and compatibly, without
changing a published API.  It also could be used to address the issue
of stdlib classes that have non-underscored members that really
shouldn't be considered part of the "public" API, but can't be renamed
now for fear of breaking code.

Usage example:

class C1:
__api__ = ['meth1', '_data2'] # read as "The API consists of meth1
and _data2."
def __init__(self):
"""documented because it's a special name"""
def meth1(self):
"""documented because it's in __api__"""
def meth2(self):
"""Shouldn't really have been exposed, but it was released that way,
   and we don't want to break users' code.
   NOT documented because it's not in __api__
   """
def _meth3(self):
"""NOT documented because it's not in __api__"""
data1 = None # not documented--not in __api__
_data2 = None # documented--it's in __api__

class C2:
__api__ = ['_data2', ...] # read as "The API includes _data2."
def __init__(self):
"""This is documented because it's a special name"""
def meth1(self):
"""documented because it follows the normal rules"""
def meth2(self):
"""documented because it follows the normal rules"""
def _meth3(self):
"""NOT documented because it's not in __api__ and starts with
underscore"""
data1 = # documented because it follows the normal rules
_data2 = None # documented--it's in __api__

Comments and criticisms welcome.

-- 
Tim Lesher 
___
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

Re: [Python-Dev] packaging

[Tarek Ziadé]

On Tue, Mar 15, 2011 at 7:50 AM, Nick Coghlan  wrote:
> On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
>  wrote:
>> Maybe this will be the killer app for the "or" enhancement
>> to the import statement. :-)
>
> Except that won't help, since even if it were added right now, pre-3.3
> compatible code couldn't use it :)

or if you backport it, we could add a new fallback ;)

try:
from __future__ import or_importer
except ImportError:
XXX <-- previous proposal
 else:
or based proposal




>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | http://ziade.org
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Michael Foord]

On 15/03/2011 07:59, Nick Coghlan wrote:

On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith  wrote:

The field names are not always under direct control of the developer, such
as when they are database column names. Not that using _replace completely
gets rid of this problem, but I agree with Raymond's decision that a field
name can be any valid identifier not starting with an underscore. It's the
simplest thing for the developer using namedtuple.

While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore to the
*end* (as_dict_, replace_, make_) as is sometimes done for code that
needs to avoid conflicting with a keyword.

Namespace collisions with actual fields would remain unlikely, while
pydoc would pick up the new names correctly.



Although it's a backwards incompatible change. Teaching pydoc to 
recognise the private methods isn't.


Michael


Cheers,
Nick.




--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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

Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.

[Antoine Pitrou]

On Tue, 15 Mar 2011 15:29:59 +0100
brian.curtin  wrote:
> +
> +def test_gz_ext(self):
[...]
> +
> +def test_bz2_ext(self):
[...]
> +
> +def test_Gz_ext(self):
> +self.do_test_use_builtin_open("abcd.Gz", 6)
> +
> +def test_Bz2_ext(self):
> +self.do_test_use_builtin_open("abcd.Bz2", 7)

Just a stylistic nit, but perhaps we should avoid having methods names
which differ in casing only?

Regards

Antoine.


___
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

Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.

[Brian Curtin]

On Tue, Mar 15, 2011 at 10:44, Antoine Pitrou  wrote:

> On Tue, 15 Mar 2011 15:29:59 +0100
> brian.curtin  wrote:
> > +
> > +def test_gz_ext(self):
> [...]
> > +
> > +def test_bz2_ext(self):
> [...]
> > +
> > +def test_Gz_ext(self):
> > +self.do_test_use_builtin_open("abcd.Gz", 6)
> > +
> > +def test_Bz2_ext(self):
> > +self.do_test_use_builtin_open("abcd.Bz2", 7)
>
> Just a stylistic nit, but perhaps we should avoid having methods names
> which differ in casing only?


Agreed. I'll rename them to be more expressive.
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 09:20, "Martin v. Löwis"  wrote:
>> In fact, since the deprecation in the Python 2 line happened in 2.7,
>> the deprecation period of this API in practice was between July 3rd
>> 2010 and February 20 2011. That is a deprecation period of somewhat
>> longer than seven months. Nobody obviously though 2.6 was out of
>> practical use by now, so why did you decide to remove one if it's
>> API's?
>
> Python 2.6's API wasn't removed in 2.7. It remains available.

But not in 3.2. And the new API appeared in 2.7. That is a deprecation
period of seven and a half months.

> If you go from 2.7 to 3.2, you should expect things to break. That's
> why the major version changed.

And 3.1 to 3.2? There is no major version break there.

> For 3.x, as Reid points out, the API was deprecated in 3.1, so the
> deprecation period was rather 19 months, not 7.

Yes, but we are now in a period of parallell support for Python 2 and
Python 3. So it doesn't work like that. We need to support both Python
2 and Python 3 at the same time. Therefore, the deprecation period was
seven and a half month, because it was impossible to support the new
API before, and impossible to support the new API after, if you need
to support both Python 2 and Python 3.

>> Let's make no bones about this: The PyCObject API should *not* have
>> been removed in 3.2. In fact, the removal should be reversed, and
>> 3.2.1 should be released ASAP, making 3.2 a moot and unsupported
>> version.
>
> This change conforms to PEP 5:
>
> "There must be at least a one-year transition period between the
> release of the transitional version of Python and the release
> of the backwards incompatible version.  Users will have at
> least a year to test their programs and migrate them from use
> of the deprecated construct to the alternative one."

It is too short, and so is 19 months, but this change does *not* conform.

//Lennart
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

[Lennart Regebro]

On Mon, Mar 14, 2011 at 19:22, Reid Kleckner  wrote:
> I don't know how your code works, but handling either type from C
> seems very straightforward to me.  You can simply use #ifdef
> Py_COBJECT_H to see if the cobject.h header was pulled into Python.h.
> Similarly for Py_CAPSULE_H.  All you lose is that if you do get a
> PyCObject, there is no way of knowing if the void pointer is of the
> right type.

Good to know.

>> **We can't deprecate an API in one version and drop the API in the
>> next. This is not acceptable. The deprecation period must be much
>> longer!**
>
> Surely, you must be joking.

No.

//Lennart
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Nick Coghlan]

On Tue, Mar 15, 2011 at 9:42 AM, Tim Lesher  wrote:
> 2. Add a new class attribute that uses the same mechanism, with a
> different name (e.g., __api__).
> Pro: fairly easy to explain; because it doesn't share a name with
> __all__ its semantics can be tweaked without confusing people.
> Con: slight additional cognitive burden of a new feature
>
> I'm implementing both of these separately this week to see which works
> better in practice.  So far I'm liking __api__ better, with these
> semantics:
>
> 1. Classes without __api__ are treated just as they are today.
> 2. __api__ on classes works just like __all__ on modules (only special
> names, plus its contents are documented)
> 3. Additionally, __api__ can take an Ellipsis.  That makes the __api__
> list additive--pydoc documents everything it normally would, *plus*
> the contents of __api__
> 4. __api__ is added to pydoc's "hidden names" list; since its only
> purpose is to help generate docs, its value would be of little use in
> the generated docs themselves.
>
> Point 3 (Ellipsis) is unusual, but to me it makes the declaration read
> well and solves the namedtuple case succinctly and compatibly, without
> changing a published API.  It also could be used to address the issue
> of stdlib classes that have non-underscored members that really
> shouldn't be considered part of the "public" API, but can't be renamed
> now for fear of breaking code.

The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually, only applying __api__ to the specific class that defined it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Nick Coghlan]

On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
 wrote:
> On 15/03/2011 07:59, Nick Coghlan wrote:
>> While I actually think the current API design is a decent compromise,
>> another option to consider would be to move the underscore to the
>> *end* (as_dict_, replace_, make_) as is sometimes done for code that
>> needs to avoid conflicting with a keyword.
>>
>> Namespace collisions with actual fields would remain unlikely, while
>> pydoc would pick up the new names correctly.
>>
>
> Although it's a backwards incompatible change. Teaching pydoc to recognise
> the private methods isn't.

If we can find a good way to do it, making pydoc smarter would
definitely be a nicer option.

If we went the "moving the underscore" route, the old names would
indeed have to remain for compatibility. Just one of many reasons it
isn't a great solution :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] packaging

[Nick Coghlan]

On Tue, Mar 15, 2011 at 9:48 AM, Tarek Ziadé  wrote:
> or if you backport it, we could add a new fallback ;)
>
> try:
>    from __future__ import or_importer
> except ImportError:
>    XXX <-- previous proposal
>  else:
>    or based proposal

Alas, the fallback trick doesn't work for the from __future__ compiler hacks.

What you could do though, is isolate the logic for the import
fallbacks and then do:

from myproject.import_fallbacks import compiler, commands

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Antoine Pitrou]

On Tue, 15 Mar 2011 11:17:18 -0400
Nick Coghlan  wrote:
> On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
>  wrote:
> > On 15/03/2011 07:59, Nick Coghlan wrote:
> >> While I actually think the current API design is a decent compromise,
> >> another option to consider would be to move the underscore to the
> >> *end* (as_dict_, replace_, make_) as is sometimes done for code that
> >> needs to avoid conflicting with a keyword.
> >>
> >> Namespace collisions with actual fields would remain unlikely, while
> >> pydoc would pick up the new names correctly.
> >>
> >
> > Although it's a backwards incompatible change. Teaching pydoc to recognise
> > the private methods isn't.
> 
> If we can find a good way to do it, making pydoc smarter would
> definitely be a nicer option.

Wouldn't a decorator be adequate?

@pydoc.public_api
def _asdict(self):
"""some docstring"""
...

Regards

Antoine.


___
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

Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.

[Nick Coghlan]

On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin  wrote:
> Agreed. I'll rename them to be more expressive.

Don't forget NEWS and ACKS updates as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP, CONTINUE_LOOP

[Eugene Toder]

> I think you guys are forgetting about FOR_ITER, listcomps, and the like.
>
> That is, IIRC, the reason loops use the block stack is because they put
> things on the regular stack, that need to be cleared off the stack when the
> loop is exited (whether normally or via an exception).

Good point. However, for exit via exception you always unwind till try
block, having loop block in the way seems unneeded?
While loops don't keep anything on values stack, so sounds like they
can avoid SETUP_LOOP?
Comprehensions don't use SETUP_LOOP already as you can't break from them.
Sounds like the only use case is for loop with explicit break. In this
case break can be compiled into POP and JUMP at the expense of
bytecode size if there are multiple breaks.

Eugene
___
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

Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.

[Brian Curtin]

On Tue, Mar 15, 2011 at 11:28, Nick Coghlan  wrote:

> On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin 
> wrote:
> > Agreed. I'll rename them to be more expressive.
>
> Don't forget NEWS and ACKS updates as well.


Got the news update in 9448691fe084. Had him in acks from another patch last
night. Thanks.
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Martin v. Löwis]

Python 2.6's API wasn't removed in 2.7. It remains available.


But not in 3.2. And the new API appeared in 2.7.


No, it didn't. It first appeared in 3.1.


That is a deprecation period of seven and a half months.


Not true. It's a deprecation period of 19 months and two
releases (3.1 and 2.7).


If you go from 2.7 to 3.2, you should expect things to break. That's
why the major version changed.


And 3.1 to 3.2? There is no major version break there.


Right. So for things to be removed there, they have to be deprecated
first (and that's what happened).


For 3.x, as Reid points out, the API was deprecated in 3.1, so the
deprecation period was rather 19 months, not 7.


Yes, but we are now in a period of parallell support for Python 2 and
Python 3. So it doesn't work like that. We need to support both Python
2 and Python 3 at the same time. Therefore, the deprecation period was
seven and a half month, because it was impossible to support the new
API before, and impossible to support the new API after, if you need
to support both Python 2 and Python 3.


If you actually had been supporting 2.x and 3.x in parallel for the last 
two years, you would have had a deprecation period of 19 months

and two releases. It's only if you are now migrating from 2 to 3
that you notice the breakage for the first time.

Regards,
Martin
___
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

Re: [Python-Dev] NetBSD and curses

[Gregory P. Smith]

Hi, Sorry, it was just laughingly pointed out to me that I responded to your
complaint about a bug being ignored by asking you to file a bug. :)  Thats
what I get for "reading" things late at night.

regardless, any time you have a patch for something, please attach it to the
issue, things on the mailing list get lost.  I've gone ahead and attached
the patch and accepted the issue.  I have a netbsd ec2 instance to test with
now but haven't had time to get it setup for python development.

None of the devs currently run netbsd on a regular basis or have much
experience with it as a platform so patches are a great help.  Any chance
you can also make a version of the patch that applies against hg cpython tip
(3.3)?

-gps

2011/3/15 Gregory P. Smith 

> Would you please post this to bugs.python.org so that it doesn't get lost?
>  thanks!
>
> -gps
>
> On Mon, Mar 14, 2011 at 8:51 PM, Bill Green  wrote:
>
>> Hi all,
>>
>> I ran across this issue several months ago and filed a bug report (#9667).
>>  It just came up again, and it doesn't look like anything's been done with
>> the bug report, so I thought I'd post here.
>>
>> In _cursesmodule.c there are a lot of preprocesser conditionals that test
>> if the system is NetBSD. In my case, the issue was that the module built
>> lacked the KEY_UP / _DOWN / etc. constants, but there are other changes as
>> well.  This is the case even if you're compiling against ncurses instead of
>> the system curses.  Αttached below is a patch against 2.7.1 that negates the
>> NetBSD conditionals if ncurses is present.  It seems to work as expected,
>> although I haven't done any real testing.  I assumed this was done because
>> NetBSD curses was missing something, but I looked at the headers and it
>> seems to have most of the constants that the compilation directives are
>> leaving out (A_INVIS, the aforementioned KEY_* constants, at least), so I'm
>> not sure why that code isn't compiled in anyway.  Please let me know if I'm
>> misunderstanding this.
>>
>> Thanks,
>> Bill
>>
>> ___
>> 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/greg%40krypto.org
>>
>>
>
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Tim Lesher]

On Tue, Mar 15, 2011 at 11:24, Antoine Pitrou  wrote:
> Wouldn't a decorator be adequate?
>
>    @pydoc.public_api
>    def _asdict(self):
>        """some docstring"""
>        ...

That was my first attempt. Unfortunately, it didn't work well with
classmethods or immutable data members, and forcing the module to
import pydoc had some bad side effects (particularly in the eval-ed
code for namedtuple).

-- 
Tim Lesher 
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Tim Lesher]

On Tue, Mar 15, 2011 at 11:15, Nick Coghlan  wrote:
> The challenge here is how it would interact with inheritance. pydoc
> couldn't use normal attribute lookup, it would have to walk the MRO
> manually, only applying __api__ to the specific class that defined it.

Great catch. I know pydoc already looks at this in the
attrs-processing loop (to group attrs by their defining class), but my
current implementation applies __api__ too early to deal with that.
I'll fix it.

Any test cases should definitely throw some diamond-pattern or even
more degenerate cases at the implementation.  What *is* the worst case
for MRO complexity?

Overall, this is becoming more interesting than I'd thought at first.
Is this something that should require a PEP?
-- 
Tim Lesher 
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

[Robert Kern]

On 3/14/11 5:30 PM, Lennart Regebro wrote:


Many projects, not only the Zope Toolkit needs to support a lot of
versions. The Zope component architecture currently supports 2.4, 2.5
and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
be dropped, but it definitely will be *years* until we can drop
support for 2.6.  But if I move the PyCObject API to the PyCapsule
API, the zope packages will **only work on Python 2.7 and 3.2**. This
is obviously not an option. If I do *not* switch, I can't support
Python 3.2. That's bad.


For what it's worth, numpy simultaneously supports Python 2.5-2.7 and 3.1-3.2. 
It uses PyCObject or PyCapsule APIs as appropriate. We do this from the same 
codebase. We had to add another layer of indirection, but nothing too bad. You 
can steal our code here:


https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_3kcompat.h#L299

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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

Re: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by Piotr Kasprzyk.

[Antoine Pitrou]

On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti  wrote:
>   Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
>   Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c

libffi is a third-party library and you should probably not introduce
gratuitous changes in these files. It will make tracking changes with
upstream more tedious.

Regards

Antoine.


___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Nick Coghlan]

On Tue, Mar 15, 2011 at 12:27 PM, Tim Lesher  wrote:
> Overall, this is becoming more interesting than I'd thought at first.
> Is this something that should require a PEP?

Yeah, just to thrash out the semantics and give some visibility into
the design decisions.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Raymond Hettinger]

One of simplest and least invasive ways to get help()
to show the underscore methods and attributes is to 
make pydoc aware of named tuples by checking for the 
presence of _fields. 

* That leaves the named tuple code as simple as possible
(which is important because the self-documenting code
is exposed to the user through the verbose option).

* It supports the _1, _2 attributes created by the rename
option, and it works with user supplied underscore methods
and attributes in a subclass.

* It doesn't exaggerate the importance of help issue
which AFAICT hasn't ever been noticed or cared about
since the introduction of named tuples a few years ago
or since the publication of its recipe in years prior to that.


Raymond


P.S.  There are other ways like creating an abstract
base class to identify a class as having underscored
names that aren't private (like _from_iterable in the
ABC for sets), but this seems to me like trying to 
kill a mosquito with a cannon.  The underlying issue
is so minor that it rules out invasive or heavy-weight
efforts.
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 12:02, "Martin v. Löwis"  wrote:
> If you actually had been supporting 2.x and 3.x in parallel for the last two
> years, you would have had a deprecation period of 19 months
> and two releases. It's only if you are now migrating from 2 to 3
> that you notice the breakage for the first time.

The code in question was ported to Python 3 last year, before both 2.7 and 3.2.

I noticed the API change now because it's gone from 3.2. That's how
most API changes gets noticed: Things stop working. And that's OK.
Deprecation periods are there to help you support multiple versions at
the same time. Deprecation notices are helpful, of course, but in this
case it doesn't help. Even if I had noticed the deprecation warning in
3.1, I wouldn't have been able to do anything about that, because 2.7
had then not been released, and the new API isn't supported in 2.6. I
therefore could not have moved to the new API *because* I support both
Python 2.x and 3.x

I could have (and still can) support it by using compatibility macros
or #ifdefs, sure. But you can do that without a deprecation period.

So: without compatibility preprocessing I can no longer support 2.6.
2.7 came out seven and a half months before 3.2. Hence the deprecation
period was in practice seven and a half months.

Admittedly, in C with the preprocessing it's less of an issue, but the
C-extensions is rapidly reaching a position where there seems to be as
much compatibility macros as there is C code... :-) How long is this
going to continue. What API's are going to be needlessly removed in
Python 3.3? Could we please cool down with the backwards
incompatibility?

//Lennart
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Martin v. Löwis]

I noticed the API change now because it's gone from 3.2. That's how
most API changes gets noticed: Things stop working. And that's OK.
Deprecation periods are there to help you support multiple versions at
the same time.


That may be the source of misunderstanding. In my understanding, that's
*not* what deprecation periods are there. Instead, they are there to
give people time to adjust to the changes before their code will break
for good. So during the deprecation period, they should start using
the new way of doing things, so that the code is ready when the old
way goes away.


Deprecation notices are helpful, of course, but in this
case it doesn't help. Even if I had noticed the deprecation warning in
3.1, I wouldn't have been able to do anything about that


Of course you could have. You could have added a version of your code
that uses capsules (just as you are probably doing now). Then, the
could would not have been broken in 3.2.


I could have (and still can) support it by using compatibility macros
or #ifdefs, sure. But you can do that without a deprecation period.


Right - and that's why the deprecation period is not about supporting
multiple versions, but to reduce the need for people to adjust their
code on a quick notice.


Could we please cool down with the backwards
incompatibility?


That's another motivation for deprecation. It gives people a chance
to intervene and ask for an extension of the deprecation period, so that
they have more time to adjust.

Regards,
Martin
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Terry Reedy]

On 3/15/2011 11:17 AM, Nick Coghlan wrote:

On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
  wrote:

On 15/03/2011 07:59, Nick Coghlan wrote:

While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore to the
*end* (as_dict_, replace_, make_) as is sometimes done for code that
needs to avoid conflicting with a keyword.

Namespace collisions with actual fields would remain unlikely, while
pydoc would pick up the new names correctly.



Although it's a backwards incompatible change. Teaching pydoc to recognise
the private methods isn't.


If we can find a good way to do it, making pydoc smarter would
definitely be a nicer option.

If we went the "moving the underscore" route, the old names would
indeed have to remain for compatibility.


However, pydoc left alone would only pick up (and publicize) the new 
names. One can argue that since the methods are not really private, they 
should have had a trailing rather than leading underscore in the first 
place. Other module classes have recently had method names aliased and 
deprecated for eventual removal, so this would not be a unique move, 
though a class factory is slightly different from a class.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] Have we lost changeset info in the buildbots

[Martin v. Löwis]

Traditionally I could see who was the committer who push change to the
buildbots. This info seems not to be (easily) available.


I have now restored that information in the buildbot. However, only 
includes the committer, not the pusher. Traditionally, they were the

same thing, but they are not anymore since the mercurial switch.
I don't know whether the pushlog is available remotely.

Regards,
Martin
___
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

Re: [Python-Dev] cpython: Fix #11509. Significantly increase test coverage for fileinput.

[Terry Reedy]

On 3/15/2011 11:57 AM, Brian Curtin wrote:

On Tue, Mar 15, 2011 at 11:28, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:

On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin
mailto:brian.cur...@gmail.com>> wrote:
 > Agreed. I'll rename them to be more expressive.

Don't forget NEWS and ACKS updates as well.


Got the news update in 9448691fe084. Had him in acks from another patch
last night. Thanks.


Great to see significant patches coming from the sprint. I hope we can 
keep some of the newer people involved in the future.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by Piotr Kasprzyk.

[Terry Reedy]

On 3/15/2011 1:00 PM, Antoine Pitrou wrote:

On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti  wrote:

   Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
   Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c


libffi is a third-party library and you should probably not introduce
gratuitous changes in these files. It will make tracking changes with
upstream more tedious.


This answers my question elsewhere of why revert real fixes. Perhaps the 
fixes could be submitted upstream.


Is that status and the restriction on changes indicated in the file?

--
Terry Jan Reedy

___
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

Re: [Python-Dev] cpython (3.1): #11515: fix several typos. Patch by Piotr Kasprzyk.

[Benjamin Peterson]

2011/3/15 Terry Reedy :
> On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
>>
>> On Tue, 15 Mar 2011 04:19:24 +0100
>> ezio.melotti  wrote:
>>>
>>>   Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
>>>   Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
>>
>> libffi is a third-party library and you should probably not introduce
>> gratuitous changes in these files. It will make tracking changes with
>> upstream more tedious.
>
> This answers my question elsewhere of why revert real fixes. Perhaps the
> fixes could be submitted upstream.

It really doesn't matter if there's typos in 3rd party libraries which
we distribute.

>
> Is that status and the restriction on changes indicated in the file?

No, because that would make updating it annoying, too. :)



-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] Have we lost changeset info in the buildbots

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/03/11 21:14, "Martin v. Löwis" wrote:
>> Traditionally I could see who was the committer who push change to the
>> buildbots. This info seems not to be (easily) available.
> 
> I have now restored that information in the buildbot. However, only
> includes the committer, not the pusher. Traditionally, they were the
> same thing, but they are not anymore since the mercurial switch.
> I don't know whether the pushlog is available remotely.

Thanks for bringing this back!.

Recording the pusher is useful, since anybody (with push privileges) can
fake commit attributions. I know that people like Mozilla actually store
this information (via a push hook, if I am not mistaken).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX/Zn5lgi5GaxT1NAQLkyAP/WmXHtvSrx2UKkH8ubRvPVNoOqJChsPor
BLjOZD3oxiM9l0EUBtgmJPVsH9yvB0fdvFj+2T3sc9Jt5eWgSE4bzgIHXsgA7aXZ
sq24yK0Vdot+F9aDTDmeHlHrv0UzpJSBQm0iI+mkUQIVCK0da/Fy/1BMuyCxjR0C
7DZCGVOzQyg=
=jmsM
-END PGP SIGNATURE-
___
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

[Python-Dev] Mercurial workflow: merging from 3.2

[Michael Foord]

Hey all,

I realise that we're still getting used to the workflows, but there are 
currently unmerged changesets (in test_peepholer and friends) on the 3.2 
branch that seem to have been applied *separately* to 3.3. This causes 
problems for anyone else who wants to merge changes from 3.2 to 3.3 as 
these unmerged changesets appear as conflicts.


If you do work in 3.2 (or earlier) please merge those changesets to default.

All the best,

Michael

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 15:39, "Martin v. Löwis"  wrote:
> Of course you could have. You could have added a version of your code
> that uses capsules (just as you are probably doing now).

No I'm not.

> Right - and that's why the deprecation period is not about supporting
> multiple versions, but to reduce the need for people to adjust their
> code on a quick notice.

I think we need to adjust PEP 5 then. We can't keep on breaking
backwards compatibility like this. People are already freaked out
about Python 2 to Python 3, and the argument is often used against
Python that it's not a language to be used in enterprise situations
because Python keeps on breaking backwards compatibility. Up until 3.2
that statement was not actually true. Python 2.x was very backwards
compatible. The next time somebody tells me that Python isn't stable
and breaks backwards compatibility all the time, and says that's why
you should use Java, what can I now say? OK, it's just the C-API, but
that excuse isn't going to fly...

//Lennart
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Nick Coghlan]

On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro  wrote:
> On Tue, Mar 15, 2011 at 15:39, "Martin v. Löwis"  wrote:
>> Of course you could have. You could have added a version of your code
>> that uses capsules (just as you are probably doing now).
>
> No I'm not.

The numpy folks have shown it is quite possible to support 3.2 without
sacrificing compatibility with earlier versions.

>> Right - and that's why the deprecation period is not about supporting
>> multiple versions, but to reduce the need for people to adjust their
>> code on a quick notice.
>
> I think we need to adjust PEP 5 then. We can't keep on breaking
> backwards compatibility like this. People are already freaked out
> about Python 2 to Python 3, and the argument is often used against
> Python that it's not a language to be used in enterprise situations
> because Python keeps on breaking backwards compatibility. Up until 3.2
> that statement was not actually true. Python 2.x was very backwards
> compatible. The next time somebody tells me that Python isn't stable
> and breaks backwards compatibility all the time, and says that's why
> you should use Java, what can I now say? OK, it's just the C-API, but
> that excuse isn't going to fly...

But given that this situation was unique to the parallel development
of 2.x and 3.x, and PEP 5 was applied correctly within each of the
parallel lines of development, why not just consider this another
instance of the 2.x/3.x incompatibility? That's what it is after all.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

[Nick Coghlan]

For years, urlparse (and subsequently urlib.parse) has opted to
implement the semantics from the older URL processing RFCs, rather
than updating to the new semantics as the RFCs are superseded.

With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out, can we finally switch to supporting
the current semantics rather than the obsolete behaviour?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 18:56, Nick Coghlan  wrote:
> why not just consider this another
> instance of the 2.x/3.x incompatibility? That's what it is after all.

Apparently not, as the code already ran under Python 3.1.

//Lennart
___
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

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

[Senthil Kumaran]

On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan  wrote:
> With RFC 3986 passing its 6th birthday, and with it being well past
> its 7th by the time 3.3 comes out, can we finally switch to supporting
> the current semantics rather than the obsolete behaviour?

We do infact, support RFC 3986, expect for the cases where those
conflict with the previous RFCs. (IOW, backwards compatible).
The tests can give you a good picture here. Do you mean, we should
just do away with backwards  compatibility? Or you had anything else
specifically in mind?

-- 
Senthil
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Antoine Pitrou]

On Tue, 15 Mar 2011 18:46:37 -0400
Lennart Regebro  wrote:
> 
> > Right - and that's why the deprecation period is not about supporting
> > multiple versions, but to reduce the need for people to adjust their
> > code on a quick notice.
> 
> I think we need to adjust PEP 5 then. We can't keep on breaking
> backwards compatibility like this.

"We"?
You must understand that compatibility rules are quite a burden when it
comes to evolving Python's APIs. Making these rules even stricter would
probably reduce motivation to contribute to Python for at least some
developers (be they core developers or not).

Beside, if you need long-term support, there is a well-known solution:
turn to a company that provides such support. That company can be called
Redhat, Canonical, ActiveState or even Apple. The community of
volunteers called python-dev is already doing quite a lot in that area.

> People are already freaked out
> about Python 2 to Python 3, and the argument is often used against
> Python that it's not a language to be used in enterprise situations
> because Python keeps on breaking backwards compatibility.

This sounds like FUD. Again, such companies can just rely on a
commercial vendor to provide support.

Regards

Antoine.


___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Greg Ewing]

Martin v. Löwis wrote:


"There must be at least a one-year transition period between the
release of the transitional version of Python and the release
of the backwards incompatible version.


I still think this is going to result in rude shocks to
people switching from 2 to 3 and jumping several releases
into the 3.x line.

--
Greg
___
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

Re: [Python-Dev] packaging

[Greg Ewing]

Tarek Ziadé wrote:


try:
from __future__ import or_importer
except ImportError:
XXX <-- previous proposal
 else:
or based proposal


This could easily be fixed if we allowed run-time access
to the time machine:

  from __future__ import temporal_mechanics, or_importer
  import timemachine
  timemachine.backport_feature("or_importer", from_version = "3.4")
  ...

(For obvious reasons, this will work despite the future
import of or_importer occurring before the code that
backports it.)

Manual use of the time machine would be required to
backport the timemachine module itself, after which
there would never be any backwards compatibility
problems again.

--
Greg
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Greg Ewing]

Nick Coghlan wrote:


The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually,


This is an instance of a pattern that I've encountered a
few times in things that I've done: you have a class
attribute containing a list of things, and you want it
to be "additive" with respect to inheritance -- i.e. it
contains the items specified in a particular class plus
all those specified in its base classes.

This can obviously be arranged using appropriate metaclass
hackery, but I'm wondering whether it could be provided
using some mechanism that can be applied orthogonally
to any class attribute.

Maybe this is another reason to have a hook somewhere
in the standard class creation process that allows a
descriptor to initialise itself with knowledge of its
environment.

--
Greg
___
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

[Python-Dev] User conversions in custom string.Formatter

[Andrew Svetlov]

As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like "{0!s}".
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.

I experimented with that last month and found it very convenient.
>From my perspective custom conversions are very close to 'filters'
from html template engines (jinja2, mako, django etc).
While I like to see custom conversions simple and easy I don't wan't
to bring 'cascading' and 'parametrization' to standard formatting.

But why don't relax spec a bit and allow to use any word (with
'identifier' semantix, I mean str.isidentifier()) as conversion name?
Proposed update doesn't make any backward incompatibility (both python
and public C API are not changed), it's clean and obvious.
And it's very funny to use words instead single characters for custom
user-specific conversions.

What do you think?
___
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

Re: [Python-Dev] User conversions in custom string.Formatter

[Eric Smith]

On 03/15/2011 08:07 PM, Andrew Svetlov wrote:

As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like "{0!s}".
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.

I experimented with that last month and found it very convenient.

From my perspective custom conversions are very close to 'filters'

from html template engines (jinja2, mako, django etc).
While I like to see custom conversions simple and easy I don't wan't
to bring 'cascading' and 'parametrization' to standard formatting.

But why don't relax spec a bit and allow to use any word (with
'identifier' semantix, I mean str.isidentifier()) as conversion name?
Proposed update doesn't make any backward incompatibility (both python
and public C API are not changed), it's clean and obvious.
And it's very funny to use words instead single characters for custom
user-specific conversions.

What do you think?


This should be in python-ideas, but I don't know if Andrew is 
subscribed, so I'll reply here until it gets out of control.


Andrew: Could you give a code sample of what you'd like to see?

Eric.
___
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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Greg Ewing]

Tim Lesher wrote:


Any test cases should definitely throw some diamond-pattern or even
more degenerate cases at the implementation.  What *is* the worst case
for MRO complexity?


I don't think that's an issue -- the MRO gets flattened into
a list at class creation time, so code that walks it never
sees any of the complexities of diamonds, etc.

--
Greg
___
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

[Python-Dev] devguide: managing "+1 heads"

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As far as I remember, python-dev decided that each branch should have a
single head. We probably have even a push hook to avoid mistakes. Or we
should :).

But we don't explain what is suppose to be done when a developer is
working in a feature, she updates her repository clone, rebase her
patches, collapses all her local changesets to a single giant changeset,
commit it locally, merge them to "default" and then she tries to push.
But somebody else "raced" her and commit first, so she is trying to
generate a new head.

The standard approach in mercurial is for her to pull the changes and to
do a merge before trying to push again (and hope nobody else "raced" her
again, this time). But the merge will be visible in the project history,
and I have the feeling that python-dev tries hard to keep a lineal history.

Another usual approach would be to "pull" the changes and "rebase" the
local unpushed changesets before trying again, to get a linear history.
But no idea of what would happen when we have multiple local commits in
several different branches. Never tried in this situation, and not sure
that I want to try :).

In any case, devguide is silent about this. I would suggest to write
something to fill this gap.

See, for instance, ,
.

PS: I didn't merged 9a817ab166e0 to "3.x" because I don't know what
plans Raymond has for 6544accfefc3. I guess he is waiting for buildbot
results before merging to 3.x.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/

j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYALuplgi5GaxT1NAQIpwgP/U7MTC59QKOn5/4PgFEe3L1q7tsiAs6Tb
jLYhL8vXBjyY3Ct5bOXW9MBcagHa+Bk/hz/ohGcGP+PL3ZtqgXE9Zv6ZXRydnhWb
GslPQnCnHjp8KMa3iE6wDMRskY46iDQtVh1QOo9UTi001jn5mqo2CLDugmFHVU+l
lFEnXBCotGo=
=SBiW
-END PGP SIGNATURE-
___
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

Re: [Python-Dev] devguide: managing "+1 heads"

[Antoine Pitrou]

On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea  wrote:
> 
> The standard approach in mercurial is for her to pull the changes and to
> do a merge before trying to push again (and hope nobody else "raced" her
> again, this time).

This is indeed the standard approach, so I'm not sure what the point of
mentioning it in the devguide would be. I don't think the devguide
should turn into a Mercurial tutorial: there are plenty of them on the
Web.

Regardless, if you want to experiment with other approaches, please go
ahead and report the results here.

Regards

Antoine.


___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou  wrote:
> Beside, if you need long-term support, there is a well-known solution:
> turn to a company that provides such support. That company can be called
> Redhat, Canonical, ActiveState or even Apple. The community of
> volunteers called python-dev is already doing quite a lot in that area.

OK, fine. I'm stopping my efforts of porting the ZTK to Python 3
unless somebody pays me then, if that is the attitude from the core
developers on this issue. Why should there be third-party libraries
available for Python 3.2!? No need, if you want them you can find
commercial support, apparently.

//Lennart
___
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

Re: [Python-Dev] devguide: managing "+1 heads"

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/03/11 02:15, Antoine Pitrou wrote:
> On Wed, 16 Mar 2011 02:00:42 +0100
> Jesus Cea  wrote:
>>
>> The standard approach in mercurial is for her to pull the changes and to
>> do a merge before trying to push again (and hope nobody else "raced" her
>> again, this time).
> 
> This is indeed the standard approach, so I'm not sure what the point of
> mentioning it in the devguide would be. I don't think the devguide
> should turn into a Mercurial tutorial: there are plenty of them on the
> Web.

My point is that I was getting the "+1 head" warning. I know how to
solve it by myself, but I checked the devguide to learn if there was
some kind of policy about it. The devguide is silent about it.

Maybe a simple "try to keep the history lineal, as possible" and "feel
free to merge heads in the standard mercurial way".

In fact, we have discussed here the approach of collapsing local changes
to a single changeset when pushing to the central repository, but I
don't see any reference to this policy in the devguide.

Unwritten "culture" is not good. Better for new contributors to read a
document and learn "the way" that to pick some details here, some there
after stepping over a lot of toes.

For instance, merging between branches (in which direction) is
established here, but not in the devguide.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYAUUZlgi5GaxT1NAQJp8wQAmuj5QLohUvAGRetajubTlizIMhgUEk1l
9kYn9XcfdtETHkM2t3Fmi73FscslNWXTT11kR1rqoyJUjS7XklcPGYtKQqWBAo+b
qICXLKo6C150lRe5VRDWBlJCvUTpFGQddh3ouTjfPjW43sO1Sj/OWJb4H1tSkyjL
smKW5SaSnXE=
=46ku
-END PGP SIGNATURE-
___
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

Re: [Python-Dev] devguide: managing "+1 heads"

[Benjamin Peterson]

2011/3/15 Jesus Cea :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 16/03/11 02:15, Antoine Pitrou wrote:
>> On Wed, 16 Mar 2011 02:00:42 +0100
>> Jesus Cea  wrote:
>>>
>>> The standard approach in mercurial is for her to pull the changes and to
>>> do a merge before trying to push again (and hope nobody else "raced" her
>>> again, this time).
>>
>> This is indeed the standard approach, so I'm not sure what the point of
>> mentioning it in the devguide would be. I don't think the devguide
>> should turn into a Mercurial tutorial: there are plenty of them on the
>> Web.
>
> My point is that I was getting the "+1 head" warning. I know how to
> solve it by myself, but I checked the devguide to learn if there was
> some kind of policy about it. The devguide is silent about it.
>
> Maybe a simple "try to keep the history lineal, as possible" and "feel
> free to merge heads in the standard mercurial way".
>
> In fact, we have discussed here the approach of collapsing local changes
> to a single changeset when pushing to the central repository, but I
> don't see any reference to this policy in the devguide.
>
> Unwritten "culture" is not good. Better for new contributors to read a
> document and learn "the way" that to pick some details here, some there
> after stepping over a lot of toes.
>
> For instance, merging between branches (in which direction) is
> established here, but not in the devguide.

What are you talking about?
http://docs.python.org/devguide/committing.html#forward-porting



-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] devguide: managing "+1 heads"

[Antoine Pitrou]

On Wed, 16 Mar 2011 02:37:21 +0100
Jesus Cea  wrote:
> 
> Maybe a simple "try to keep the history lineal, as possible" and "feel
> free to merge heads in the standard mercurial way".

Well, can you propose a patch to add or improve wording?

> For instance, merging between branches (in which direction) is
> established here, but not in the devguide.

It is:
http://docs.python.org/devguide/committing.html#forward-porting

Regards

Antoine.


___
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

Re: [Python-Dev] devguide: managing "+1 heads"

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/03/11 02:42, Benjamin Peterson wrote:
>> For instance, merging between branches (in which direction) is
>> established here, but not in the devguide.
> 
> What are you talking about?
> http://docs.python.org/devguide/committing.html#forward-porting

I beg your pardon. 3AM in Spain. Time to get some sleep, it seems...

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYAWOZlgi5GaxT1NAQJD6gP5AbqT+PP/1DPmzVUXy0iqWuy+HE1PJC6X
dBzvE3abcqCsCEIhmqn8NW//jXUzGZ162dF+3xJ9IViCZhOol3n5d+E/Yna67/uh
48LJIV0bUrXDkg/nm0/VJGyx0GUqFx546mv9M3dsjMOxd7Q6ZbSfCp/clyWa8Drn
IwfdJMkGnAI=
=NW3O
-END PGP SIGNATURE-
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Antoine Pitrou]

On Tue, 15 Mar 2011 21:16:58 -0400
Lennart Regebro  wrote:
> On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou  wrote:
> > Beside, if you need long-term support, there is a well-known solution:
> > turn to a company that provides such support. That company can be called
> > Redhat, Canonical, ActiveState or even Apple. The community of
> > volunteers called python-dev is already doing quite a lot in that area.
> 
> OK, fine. I'm stopping my efforts of porting the ZTK to Python 3
> unless somebody pays me then, if that is the attitude from the core
> developers on this issue.

I don't know what other core devs, but I don't think this discussion is
going anywhere. If porting the ZTK is a burden for you, perhaps you
should try to find some financial support for it (or let other people
do it for you), rather than accusing the python-dev community.

Regards

Antoine.
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou  wrote:
> I don't know what other core devs, but I don't think this discussion is
> going anywhere. If porting the ZTK is a burden for you, perhaps you
> should try to find some financial support for it (or let other people
> do it for you), rather than accusing the python-dev community.

Up until the reactions from the core Python developers on these real
world problems, it was hard work, but also fun. It isn't anymore, and
I hear your message, loud and clear, so indeed, somebody else will
have to do it. I've lost interest.

//Lennart
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Senthil Kumaran]

On Tue, Mar 15, 2011 at 10:14:12PM -0400, Lennart Regebro wrote:
> Up until the reactions from the core Python developers on these real
> world problems, it was hard work, but also fun. 

It is still. The majority of the responses were informative on
backwards compatibility and release process. And suggestive of how
things changed from between 2.7, 3.1 and 3.2. And there is a unique
problem here that 3.1 was released before 2.7.

And things which break backwards compatibility is discussed before any
changes are made. So, your comment on python 'always breaking the
compatibility' was not correct and perhaps that invoked a strong
reaction.

-- 
Senthil
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Guido van Rossum]

On Tue, Mar 15, 2011 at 7:14 PM, Lennart Regebro  wrote:
> On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou  wrote:
>> I don't know what other core devs, but I don't think this discussion is
>> going anywhere. If porting the ZTK is a burden for you, perhaps you
>> should try to find some financial support for it (or let other people
>> do it for you), rather than accusing the python-dev community.
>
> Up until the reactions from the core Python developers on these real
> world problems, it was hard work, but also fun. It isn't anymore, and
> I hear your message, loud and clear, so indeed, somebody else will
> have to do it. I've lost interest.

This is unfortunate (and the PyCon sprints aren't even over!).

I think Lennart's complaint has *some* validity. I think PEP 5 did not
anticipate two overlapping lines of development, and in retrospect it
was unwise to kill the offending API in 3.2 (even if it is *possible*
to deal with it, it's cumbersome).

But I do not think that there is a way to undo the damage that was
done; putting the missing API back in 3.2.1 will cause other problems
(because it would break compatibility between 3.2 and 3.2.1). So
Lennart will have to put up with the pragmatics of supporting 2.7 and
3.2 (and others as he desires). But we should learn from the
experience and be more cautious with 3.3.

Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[James Y Knight]

On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote:

> On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou  wrote:
>> I don't know what other core devs, but I don't think this discussion is
>> going anywhere. If porting the ZTK is a burden for you, perhaps you
>> should try to find some financial support for it (or let other people
>> do it for you), rather than accusing the python-dev community.
> 
> Up until the reactions from the core Python developers on these real
> world problems, it was hard work, but also fun. It isn't anymore, and
> I hear your message, loud and clear, so indeed, somebody else will
> have to do it. I've lost interest.

It seems a bit odd for you to be so surprised about this, considering Python3 
is a *huge* compatibility break that broke basically every single thing ever 
written in Python.

And I'm not sure why you're making such a big deal about this one corner of 
incompatibility -- PyCObject vs. PyCapsule seems like such a trivial and easy 
to work around issue compared to the massive pain-in-the-ass porting job for 
all the incompatibilities on the Python-language side of the fence.

James
___
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

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

[Nick Coghlan]

On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran  wrote:
> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan  wrote:
>> With RFC 3986 passing its 6th birthday, and with it being well past
>> its 7th by the time 3.3 comes out, can we finally switch to supporting
>> the current semantics rather than the obsolete behaviour?
>
> We do infact, support RFC 3986, expect for the cases where those
> conflict with the previous RFCs. (IOW, backwards compatible).
> The tests can give you a good picture here. Do you mean, we should
> just do away with backwards  compatibility? Or you had anything else
> specifically in mind?

Backwards compatible with *what* though?

For the decimal module, we treat deviations from spec as bug fixes and
update accordingly, even if this changes behaviour.

For URL parsing, the spec has changed (6 years ago!), but we still
don't provide a spec-conformant implementation, even via a flag or new
function.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 22:42, Guido van Rossum  wrote:
> Fortunately there may not be any more such cases since no new major
> versions of Python 2 will be released. So I'm not sure what an update
> of PEP 5 will buy us.

That is a good point. But at least making sure no more API's get
deprecated in 3.3 (and preferably 3.4) would go a long way, as we are
likely to still have to support Python 2 in parallell for those
versions as well.

//Lennart
___
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

Re: [Python-Dev] devguide: managing "+1 heads"

[Nick Coghlan]

On Tue, Mar 15, 2011 at 9:15 PM, Antoine Pitrou  wrote:
> On Wed, 16 Mar 2011 02:00:42 +0100
> Jesus Cea  wrote:
>>
>> The standard approach in mercurial is for her to pull the changes and to
>> do a merge before trying to push again (and hope nobody else "raced" her
>> again, this time).
>
> This is indeed the standard approach, so I'm not sure what the point of
> mentioning it in the devguide would be. I don't think the devguide
> should turn into a Mercurial tutorial: there are plenty of them on the
> Web.

Given our stated preference for pushing collapsed changesets, it does
seem worthwhile to explicitly mention the pull/merge/push case as a
case where a collapsed changeset isn't expected.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Lennart Regebro]

On Tue, Mar 15, 2011 at 22:58, Lennart Regebro  wrote:
> That is a good point. But at least making sure no more API's get
> deprecated in 3.3 (and preferably 3.4)

I meant removed.
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Eric Smith]

On 3/15/2011 10:58 PM, Lennart Regebro wrote:

On Tue, Mar 15, 2011 at 22:42, Guido van Rossum  wrote:

Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.


That is a good point. But at least making sure no more API's get
deprecated in 3.3 (and preferably 3.4) would go a long way, as we are
likely to still have to support Python 2 in parallell for those
versions as well.


I think it's valid that we should consider the affect of libraries that 
are trying to support 2.x and 3.y  (for some values of x and y) at the 
same time. Speaking for myself, I'll admit I hadn't thought of this 
during any discussions of changing APIs. We'll only have to consider 
this for at most 2 more 3.x releases, if we believe the 5 year timeframe 
(since 3.0) for most projects to migrate.


But I agree that there's not much we can do in the capsule case. The 
ship has sailed on that one.


Eric.
___
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

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

[Guido van Rossum]

On Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan  wrote:
> On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran  wrote:
>> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan  wrote:
>>> With RFC 3986 passing its 6th birthday, and with it being well past
>>> its 7th by the time 3.3 comes out, can we finally switch to supporting
>>> the current semantics rather than the obsolete behaviour?
>>
>> We do infact, support RFC 3986, expect for the cases where those
>> conflict with the previous RFCs. (IOW, backwards compatible).
>> The tests can give you a good picture here. Do you mean, we should
>> just do away with backwards  compatibility? Or you had anything else
>> specifically in mind?
>
> Backwards compatible with *what* though?
>
> For the decimal module, we treat deviations from spec as bug fixes and
> update accordingly, even if this changes behaviour.
>
> For URL parsing, the spec has changed (6 years ago!), but we still
> don't provide a spec-conformant implementation, even via a flag or new
> function.

Can you be specific? What is different between those RFCs?

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

[Senthil Kumaran]

Nick Coghlan wrote:
> 
> Backwards compatible with *what* though?

I meant the parsing 'behavior'.

> For the decimal module, we treat deviations from spec as bug fixes and
> update accordingly, even if this changes behaviour.
> 
> For URL parsing, the spec has changed (6 years ago!), but we still
> don't provide a spec-conformant implementation, even via a flag or new
> function.

If I understand correctly, by spec-comformant implementation, you mean
having the parsed components denoted by the same terminology (as well
as behavior) as written in the RFC3986. 

Like the example in the url denote:


 foo://example.com:8042/over/there?name=ferret#nose
 \_/   \__/\_/ \_/ \__/
  |   ||||
   scheme authority   pathquery   fragment
  |   _|__
 / \ /\
 urn:example:animal:ferret:nose

If I send the same url's via urlparse at the moment, I would get:

>>> urlparse('foo://example.com:8042/over/there?name=ferret#nose')
ParseResult(scheme='foo', netloc='example.com:8042', 
path='/over/there?name=ferret#nose', params='', query='', fragment='')
>>> urlparse('urn:example:animal:ferret:nose')
ParseResult(scheme='urn', netloc='', path='example:animal:ferret:nose', 
params='', query='', fragment='')

The first one is because, we still have "old" scheme specific parsing behavior.
Where foo is an unrecognized scheme so everything was classified under path. If
we have valid scheme name, then the parsing behaviour would match the
expectation.

- A change to this would break the compatibility with older parsing behavior.

Another point to note is naming - We use 'netloc' as part name loosely, where
as 'authority' is correct term to use and then authority component has
sub-parts.  

- I think, it is good to change this and adopt the RFC terminology more 
rigorously.

I am +1 to any helpful improvement we can do in this module. But often it
noticed that any slightest changes in parsing behavior has caused harm and
brought us more bug-reports.

A new function, which can given this behavior is also a good idea.

-- 
Senthil
___
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

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

[Fred Drake]

On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran  wrote:
> A new function, which can given this behavior is also a good idea.

I'm strongly in favor of this approach.  I know we've been bitten by
changes made in the past, and have had to introduce Python-version
specific handling.  (I don't have the details handy, but vaguely
recall the two versions involved being 2.4 and 2.6.)


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late"

[Stefan Behnel]

Lennart Regebro, 16.03.2011 00:04:

On Tue, Mar 15, 2011 at 18:56, Nick Coghlan wrote:

why not just consider this another
instance of the 2.x/3.x incompatibility? That's what it is after all.


Apparently not, as the code already ran under Python 3.1.


Personally, I would expect that breaking backwards compatibility in Python 
3.2 affects a lot less people than a similar change in the 2.x line because 
many projects still haven't ported their code to Python 3.x.


I can assure you that it's quite easy to support both PyCObject and 
PyCapsule at the same time, thus supporting a wide range of Python 2.x and 
3.x releases. NumPy does it, Cython does it, other projects probably do it 
by now, too.


So this is actually less of a problem than you are trying to make it appear.

Stefan

___
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