Re: [Twisted-Python] Does anyone need / make use of SSHTransportAddress introduced in 12.1 ?

[Glyph]

> On Mar 17, 2015, at 11:51 PM, Adi Roiban  wrote:
> 
> On 18 March 2015 at 05:30, Glyph  > wrote:
>> 
>> On Mar 17, 2015, at 6:44 AM, Adi Roiban  wrote:
>> 
>> Hi,
>> 
>> While trying to fix https://twistedmatrix.com/trac/ticket/5999 I found
>> out about the SSHTransportAddress introduced in 12.1.
>> 
>> SSHTransportAddress is just an IAddress wrapping in a non-tranparent
>> way another IAddress.
>> 
>> It was introduces in #2997 which was accepted without any reason why
>> we need SSHTransportAddress and why SSHTransportAddress is better than
>> an IAddress.
>> I could not find any documentation describing why we need this new class.
>> 
>> 
>> The reason that we need this new type of address is to ensure that any code
>> inspecting this address and attempting to construct a similar connection
>> based upon it is not mislead into creating a transport which is not similar
>> to the one it is indicating.
>> 
>> Arguably, SSHTransportAddress is missing lots of important information: is
>> the address indicative of a client, or a server?  If a client, what hostname
>> was specified?  If a server, what user is connected?  Two SSH connections to
>> the same IP address / port number are not necessarily equivalent, but the
>> current implementation of SSHTransportAddress would compare that way, which
>> is unfortunate.
> 
> [snip]
> 
>> SSHTransportAddress is useful, but its only utility is in explicitly
>> breaking use-cases that in fact should not work, so it's a bit user-hostile,
>> so I can see why you'd feel it is useless.  If it were retrofitted to keep
>> enough information to be useful in its own right, then that would be a lot
>> better.
> 
> Thanks!

No problem, always happy to explain :).

> Are these design notes for SSHTransportAddress documented somewhere?

Doubtful.  They seem like an obvious consequence of how the various pieces fit 
together, for me; I feel like every IAddress implementer would have to contain 
a similar comment, if it were documented anywhere.  However, this really should 
be written somewhere that people, especially twisted maintainers, will see it.  
Any suggestions?

> I will update my changes to start making use of SSHTransportAddress.

Great.

> I have created a ticket to add client/server information into the
> SSHTransportAddress. I am using this as a pretext to try to improve
> the documentation for SSHTransportAddress.
> https://twistedmatrix.com/trac/ticket/7825#ticket 
> 

Thanks!

-g___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] twistechecker and twisted-dev-tools as part of twisted main repo

[Adi Roiban]

On 18 March 2015 at 05:43, Glyph  wrote:
>
>> On Mar 16, 2015, at 2:17 AM, Adi Roiban  wrote:
>
[snip]

> I'm approximately -0 on this.  I don't like the idea of dumping a bunch of
> code into the main Twisted repo that isn't distributed along with Twisted
> (personally I cannot wait to get rid of the "admin" directory entirely), but
> I also see your point about the tool being a part of the process.

>> Twistedchecker  has become an important part of dev process and I feel
>> that the reviews for this project should be more visible.

> To be fair we are only just now getting down to a reasonable latency on
> Twisted reviews, and it is still a fairly small audience reviewing.  This
> may just lengthen the Twisted review queue :).

As commented earlier, any tickets which sits idle in the review queue
for more than 1 week is not reasonable for me

Some changes in twistedchecker are there to help you with general
review process so if we land them first future reviews might be faster
as you no longer have to stop and check for false positives in
twistedchecker builder.

I don't agree with your priority... but judging by the fact that
pyflakes patches took so long to land and nobody is pissed of by
twistedchecker I feel in minority :(
For me improving the infrastructure and the tools used by the
developers is more important than the Twisted code itself.

It seems to me that you are suggesting that we can build a state of
the art skyscraper with bamboo scaffolding and only use our bare hands
and later we can look into creating power tools and advanced cranes
and scaffolding.

Maybe we are used with the fact that you can only run static code
analysis on buildbot and for that you need a commit and to manually
trigger a build by filling a web form and wait 2 minutes for results,
but this is stone age :(

pyflakes and twistedchecker should run in less than 1 second on local
computer. To optimize speed the checker should be smart and only check
the files which have changes since trunk.

-

What I am trying to do is to convince other Twisted developers that
tools and infrastructure are important and they should be top
priority.
I am advocating for replacing primitive tools.

The current review process is a pain for new non-commiter
contributors. Read-only clone of svn, manual patches attached to trac,
review commend digested into a single comment, new branches created
for conflicting changes... etc

Developing good tools take a lot of effort... so does writing good
tests. Tools should be at least as important as the code or the tests
. In fact, tests are just a tool to help you develop code.

> So, I do have an alternate proposal - perhaps you should just announce
> changes to twistedchecker on this list, and land changes to it without
> review if nobody objects within a week or so.  If you're making changes that
> are time-sensitive and there is an insufficient community to participate in
> reviews, then I think it's fair to say that they shouldn't be reviewed.  If
> anyone objects to the changes that are going in, they can always sign up to
> do reviews :).  I have implicitly instituted such a process for
> Twisted-umbrella projects like Imaginary and Vertex, where there are not
> enough active contributors to sustain development.
>

Beside twistedchecker there are also twisted-dev-tools and the repos
from twisted-infra organization.

I am not happy about cowboy / one man show coding. Merging a change
without a review as this will break things for sure.

My alternate proposal is to try to raise awareness that good tools are
at least as important as good tests and have more people reviewing
code for tools and work on improving the tools and to consider them an
integral part of the development process.

Cheers!
-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] twistechecker and twisted-dev-tools as part of twisted main repo

[Glyph]

> On Mar 18, 2015, at 1:38 AM, Adi Roiban  wrote:
> 
> On 18 March 2015 at 05:43, Glyph  wrote:
>> 
>>> On Mar 16, 2015, at 2:17 AM, Adi Roiban  wrote:
>> 
> [snip]
> 
>> I'm approximately -0 on this.  I don't like the idea of dumping a bunch of
>> code into the main Twisted repo that isn't distributed along with Twisted
>> (personally I cannot wait to get rid of the "admin" directory entirely), but
>> I also see your point about the tool being a part of the process.
> 
>>> Twistedchecker  has become an important part of dev process and I feel
>>> that the reviews for this project should be more visible.
> 
>> To be fair we are only just now getting down to a reasonable latency on
>> Twisted reviews, and it is still a fairly small audience reviewing.  This
>> may just lengthen the Twisted review queue :).
> 
> As commented earlier, any tickets which sits idle in the review queue
> for more than 1 week is not reasonable for me
> 
> Some changes in twistedchecker are there to help you with general
> review process so if we land them first future reviews might be faster
> as you no longer have to stop and check for false positives in
> twistedchecker builder.

Annoying issues with twistedchecker are certainly a problem, and I don't want 
to dissuade you from working on them, but to be honest, they have not been a 
significant source of blockers for me lately.  I have reviewed plenty of 
tickets this month  and twistedchecker 
rarely came up.  Now, granted, this is probably partly because of your other 
recent work, so, it's certainly valuable.

> I don't agree with your priority... but judging by the fact that
> pyflakes patches took so long to land and nobody is pissed of by
> twistedchecker I feel in minority :(
> For me improving the infrastructure and the tools used by the
> developers is more important than the Twisted code itself.
> 
> It seems to me that you are suggesting that we can build a state of
> the art skyscraper with bamboo scaffolding and only use our bare hands
> and later we can look into creating power tools and advanced cranes
> and scaffolding.
> 
> Maybe we are used with the fact that you can only run static code
> analysis on buildbot and for that you need a commit and to manually
> trigger a build by filling a web form and wait 2 minutes for results,
> but this is stone age :(
> 
> pyflakes and twistedchecker should run in less than 1 second on local
> computer. To optimize speed the checker should be smart and only check
> the files which have changes since trunk.

Twisted should also seamlessly parallelize over multiple cores.  It should also 
have good operational visibility, tracing, and a clearly-documented deployment 
story.  It does not strike me that any of these are substantially more 
important than the others.  While the tools aren't great, what I have spent 
most of my time struggling with lately is how to document things clearly, not 
tool issues.

> -
> 
> What I am trying to do is to convince other Twisted developers that
> tools and infrastructure are important and they should be top
> priority.
> I am advocating for replacing primitive tools.
> 
> The current review process is a pain for new non-commiter
> contributors. Read-only clone of svn, manual patches attached to trac,
> review commend digested into a single comment, new branches created
> for conflicting changes... etc

In my mind, the biggest tools problem is getting us onto a DVCS (which means 
"git" since git has won the DVCS wars). That means being able to deploy a 
testing site to make sure we haven't broken stuff, which means a Vagrantfile 
for braid.  I put in quite a lot of effort improving the state of our build 
farm earlier in the year, and ops stuff is only so rewarding, so I'm still a 
little burnt out on that.

If we had a DVCS though, the current conflicts on the logging branch would be 
easy to resolve, and as it stands they're not.  Many of the other issues you're 
talking about are hypothetically a big issue but this one is practically 
affecting progress a lot, since all of the builds are failing and multiple 
branches now need to be manually rebased.

> Developing good tools take a lot of effort... so does writing good
> tests. Tools should be at least as important as the code or the tests
> . In fact, tests are just a tool to help you develop code.

No argument there.  But there's plenty of testing we don't have either - fuzz 
testing, for example.  Our performance tests are kind of a mess, and we don't 
have alerting on performance regressions.  No one of these issues strikes me as 
obviously the #1 out there, overriding everything else that's going on with the 
project.

>> So, I do have an alternate proposal - perhaps you should just announce
>> changes to twistedchecker on this list, and land changes to it without
>> review if nobody objects within a week or so.  If you're making changes that
>> are time-sensitive and there is an insuffic

Re: [Twisted-Python] Does anyone need / make use of SSHTransportAddress introduced in 12.1 ?

[exarkun]

On 17 Mar, 01:44 pm, a...@roiban.ro wrote:


Am I the only one who fails to see the advantages of using
SSHTransportAddress over a normal IAddress?


This doesn't make any sense.  `IAddress` has no attributes or methods. 
You can't do *anything* with an object that only provides `IAddress`.


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[HawkOwl]

Hi,

As Python 2.6 has been officially abandoned for a year+ (and will receive no 
further official security updates) and Python 2.7 has been available for almost 
five years, it might be time to put Python 2.6 support to bed. The only 
currently supported distro that has Python 2.6 is RHEL6, and RHEL7 with Python 
2.7 has now been out for a year.

This would be in line with other major projects (eg. Django, Plone) and 
Python's porting guide 
(https://docs.python.org/3/howto/pyporting.html#drop-support-for-python-2-6-and-older).
 We can also remove some things from TestCase, and there's random smatterings 
of 2.6 support workarounds/comments that we could also remove.

As such, I think we should make 15.1 the final release which officially 
supports Python 2.6.

Any objections?

- Hawkie


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] twistechecker and twisted-dev-tools as part of twisted main repo

[Adi Roiban]

Ok. Let's focus on Git then.

My biggest annoyance is buildbot and the builders with false positives.

Is this the only wiki page documenting the progress and next steps for
git migration  https://twistedmatrix.com/trac/wiki/Infrastructure/SwitchToGit

I have started working at vagrant file but the changes are not
reviewed since 8 Feb https://github.com/twisted-infra/braid/pull/77

I can donate time to work on this, just let me know what can I do :)

Cheers
-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Does anyone need / make use of SSHTransportAddress introduced in 12.1 ?

[Adi Roiban]

On 18 March 2015 at 10:33,   wrote:
> On 17 Mar, 01:44 pm, a...@roiban.ro wrote:
>>
>>
>> Am I the only one who fails to see the advantages of using
>> SSHTransportAddress over a normal IAddress?
>
>
> This doesn't make any sense.  `IAddress` has no attributes or methods. You
> can't do *anything* with an object that only provides `IAddress`.
>
> Jean-Paul

True. I was thinking at IPv4Address and IPv6Address.

Thanks for the follow up. I have change  getHost and getPeer for conch
to return SSHTransportAddress and pushed changes for review.

-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Adi Roiban]

Nope. Not for my part. +1 for removing it.

Thanks!

-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Itamar Turner-Trauring]

 

+1 ___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Phil Mayers]

On 18/03/15 10:45, HawkOwl wrote:

Hi,

As Python 2.6 has been officially abandoned for a year+ (and will
receive no further official security updates) and Python 2.7 has been
available for almost five years, it might be time to put Python 2.6
support to bed. The only currently supported distro that has Python
2.6 is RHEL6, and RHEL7 with Python 2.7 has now been out for a year.

This would be in line with other major projects (eg. Django, Plone)
and Python's porting guide
(https://docs.python.org/3/howto/pyporting.html#drop-support-for-python-2-6-and-older).
We can also remove some things from TestCase, and there's random
smatterings of 2.6 support workarounds/comments that we could also
remove.

As such, I think we should make 15.1 the final release which
officially supports Python 2.6.

Any objections?


Objectively it seems reasonable.

Subjectively, it'll substantially inconvenience me (and others who have 
RH/CentOS 6 systems which will be in service for years more).


In the past, we've built and deployed a newer Python when this has 
happened e.g. RHEL4/5. That was a huge pain in the arse, and we don't 
intend to repeat it. Absent an EPEL package for python27, I suspect many 
people will do what we intend to do - stop updating Twisted.


Expect to see queries from people on older versions they can't update 
for some time ;o)


In all seriousness, I guess it depends on how useful this is. Being "in 
line" with other projects doesn't seem like a useful goal - who cares 
what Plone does? If it's useful for Twisted, then do it.


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Donald Stufft]

> On Mar 18, 2015, at 8:24 AM, Phil Mayers  wrote:
> 
> On 18/03/15 10:45, HawkOwl wrote:
>> Hi,
>> 
>> As Python 2.6 has been officially abandoned for a year+ (and will
>> receive no further official security updates) and Python 2.7 has been
>> available for almost five years, it might be time to put Python 2.6
>> support to bed. The only currently supported distro that has Python
>> 2.6 is RHEL6, and RHEL7 with Python 2.7 has now been out for a year.
>> 
>> This would be in line with other major projects (eg. Django, Plone)
>> and Python's porting guide
>> (https://docs.python.org/3/howto/pyporting.html#drop-support-for-python-2-6-and-older).
>> We can also remove some things from TestCase, and there's random
>> smatterings of 2.6 support workarounds/comments that we could also
>> remove.
>> 
>> As such, I think we should make 15.1 the final release which
>> officially supports Python 2.6.
>> 
>> Any objections?
> 
> Objectively it seems reasonable.
> 
> Subjectively, it'll substantially inconvenience me (and others who have 
> RH/CentOS 6 systems which will be in service for years more).
> 
> In the past, we've built and deployed a newer Python when this has happened 
> e.g. RHEL4/5. That was a huge pain in the arse, and we don't intend to repeat 
> it. Absent an EPEL package for python27, I suspect many people will do what 
> we intend to do - stop updating Twisted.
> 
> Expect to see queries from people on older versions they can't update for 
> some time ;o)
> 
> In all seriousness, I guess it depends on how useful this is. Being "in line" 
> with other projects doesn't seem like a useful goal - who cares what Plone 
> does? If it's useful for Twisted, then do it.
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Isn’t the RHEL answer here to just use SCLs to install Python 2.7?

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Phil Mayers]

On 18/03/15 12:29, Donald Stufft wrote:


Isn’t the RHEL answer here to just use SCLs to install Python 2.7?


I've never actually come across the SCL stuff before. Thanks for the 
pointer.


My latter point still stands - don't do it because others do it, do it 
because it's good for Twisted (or not ;o)


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[HawkOwl]

> On 18 Mar 2015, at 21:02, Phil Mayers  wrote:
> 
> On 18/03/15 12:29, Donald Stufft wrote:
> 
>> Isn’t the RHEL answer here to just use SCLs to install Python 2.7?
> 
> I've never actually come across the SCL stuff before. Thanks for the pointer.
> 
> My latter point still stands - don't do it because others do it, do it 
> because it's good for Twisted (or not ;o)

Yes, it's good for Twisted -- but I was mentioning that it's also something 
that other projects have done, so it's not like it's a crazy idea :)

- Hawkie


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] __nonzero__ for Deferred

[Glyph Lefkowitz]

I'd like to deprecate and remove __nonzero__ on Deferreds.  Occasionally I see 
code where someone (maybe even me) does "if d:" where they should have been 
doing "@d.addCallback def cb(result): if result: ...".

Anybody else have this issue?  Objections?

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] twistechecker and twisted-dev-tools as part of twisted main repo

[Glyph Lefkowitz]

> On Mar 18, 2015, at 3:55 AM, Adi Roiban  wrote:
> 
> Ok. Let's focus on Git then.
> 
> My biggest annoyance is buildbot and the builders with false positives.
> 
> Is this the only wiki page documenting the progress and next steps for
> git migration  https://twistedmatrix.com/trac/wiki/Infrastructure/SwitchToGit
> 
> I have started working at vagrant file but the changes are not
> reviewed since 8 Feb https://github.com/twisted-infra/braid/pull/77
> 
> I can donate time to work on this, just let me know what can I do :)

OK, cool.  I didn't realize that was ready for review.  I am liking the process 
we have for Mimic for flagging PRs with keywords - 
https://github.com/rackerlabs/mimic/pulls 
 - but this needs automation so as 
not to be unfriendly to non-committer contributors.

I'll try to get to it by the end of the week.

-g___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Glyph Lefkowitz]

> On Mar 18, 2015, at 5:29 AM, Donald Stufft  wrote:
> 
> 
>> On Mar 18, 2015, at 8:24 AM, Phil Mayers  wrote:
>> 
>> On 18/03/15 10:45, HawkOwl wrote:
>>> Hi,
>>> 
>>> As Python 2.6 has been officially abandoned for a year+ (and will
>>> receive no further official security updates) and Python 2.7 has been
>>> available for almost five years, it might be time to put Python 2.6
>>> support to bed. The only currently supported distro that has Python
>>> 2.6 is RHEL6, and RHEL7 with Python 2.7 has now been out for a year.
>>> 
>>> This would be in line with other major projects (eg. Django, Plone)
>>> and Python's porting guide
>>> (https://docs.python.org/3/howto/pyporting.html#drop-support-for-python-2-6-and-older).
>>> We can also remove some things from TestCase, and there's random
>>> smatterings of 2.6 support workarounds/comments that we could also
>>> remove.
>>> 
>>> As such, I think we should make 15.1 the final release which
>>> officially supports Python 2.6.
>>> 
>>> Any objections?
>> 
>> Objectively it seems reasonable.
>> 
>> Subjectively, it'll substantially inconvenience me (and others who have 
>> RH/CentOS 6 systems which will be in service for years more).
>> 
>> In the past, we've built and deployed a newer Python when this has happened 
>> e.g. RHEL4/5. That was a huge pain in the arse, and we don't intend to 
>> repeat it. Absent an EPEL package for python27, I suspect many people will 
>> do what we intend to do - stop updating Twisted.
>> 
>> Expect to see queries from people on older versions they can't update for 
>> some time ;o)
>> 
>> In all seriousness, I guess it depends on how useful this is. Being "in 
>> line" with other projects doesn't seem like a useful goal - who cares what 
>> Plone does? If it's useful for Twisted, then do it.
>> 
>> ___
>> Twisted-Python mailing list
>> Twisted-Python@twistedmatrix.com
>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> 
> Isn’t the RHEL answer here to just use SCLs to install Python 2.7?

Rather than just suggest we preserve the status quo and stay on 2.6 forever to 
do indefinite free work to support Red Hat's obsolescence business, perhaps we 
should make a condition of dropping 2.6 support being a clear guide for getting 
a Twisted environment with py2.7 up and running on whatever appropriately 
decrepit environment is popular in the CentOS/RHEL user community?  I am 
annoyed with RH for lagging so much, but I don't want to make their customers' 
employees suffer for it.

Phil - I do have a question though, since you seem to be a real life user with 
this use-case :).  If you want to use an old, unsupported version of Python, 
why do you want to deploy a new, updated version of Twisted on it?

dstufft - is there a PyPy EPEL?  As long as we're telling people to change 
which Python to use, perhaps we should point them at an actually good one ;).

-glyph



___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[Donald Stufft]

> On Mar 18, 2015, at 7:57 PM, Glyph Lefkowitz  wrote:
> 
>> 
>> On Mar 18, 2015, at 5:29 AM, Donald Stufft  wrote:
>> 
>> 
>>> On Mar 18, 2015, at 8:24 AM, Phil Mayers  wrote:
>>> 
>>> On 18/03/15 10:45, HawkOwl wrote:
 Hi,
 
 As Python 2.6 has been officially abandoned for a year+ (and will
 receive no further official security updates) and Python 2.7 has been
 available for almost five years, it might be time to put Python 2.6
 support to bed. The only currently supported distro that has Python
 2.6 is RHEL6, and RHEL7 with Python 2.7 has now been out for a year.
 
 This would be in line with other major projects (eg. Django, Plone)
 and Python's porting guide
 (https://docs.python.org/3/howto/pyporting.html#drop-support-for-python-2-6-and-older).
 We can also remove some things from TestCase, and there's random
 smatterings of 2.6 support workarounds/comments that we could also
 remove.
 
 As such, I think we should make 15.1 the final release which
 officially supports Python 2.6.
 
 Any objections?
>>> 
>>> Objectively it seems reasonable.
>>> 
>>> Subjectively, it'll substantially inconvenience me (and others who have 
>>> RH/CentOS 6 systems which will be in service for years more).
>>> 
>>> In the past, we've built and deployed a newer Python when this has happened 
>>> e.g. RHEL4/5. That was a huge pain in the arse, and we don't intend to 
>>> repeat it. Absent an EPEL package for python27, I suspect many people will 
>>> do what we intend to do - stop updating Twisted.
>>> 
>>> Expect to see queries from people on older versions they can't update for 
>>> some time ;o)
>>> 
>>> In all seriousness, I guess it depends on how useful this is. Being "in 
>>> line" with other projects doesn't seem like a useful goal - who cares what 
>>> Plone does? If it's useful for Twisted, then do it.
>>> 
>>> ___
>>> Twisted-Python mailing list
>>> Twisted-Python@twistedmatrix.com
>>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>> 
>> Isn’t the RHEL answer here to just use SCLs to install Python 2.7?
> 
> Rather than just suggest we preserve the status quo and stay on 2.6 forever 
> to do indefinite free work to support Red Hat's obsolescence business, 
> perhaps we should make a condition of dropping 2.6 support being a clear 
> guide for getting a Twisted environment with py2.7 up and running on whatever 
> appropriately decrepit environment is popular in the CentOS/RHEL user 
> community?  I am annoyed with RH for lagging so much, but I don't want to 
> make their customers' employees suffer for it.
> 
> Phil - I do have a question though, since you seem to be a real life user 
> with this use-case :). If you want to use an old, unsupported version of 
> Python, why do you want to deploy a new, updated version of Twisted on it?
> 
> dstufft - is there a PyPy EPEL?  As long as we're telling people to change 
> which Python to use, perhaps we should point them at an actually good one ;).
> 

It looks like EPEL has PyPy 2.0.2, I don’t see it in SCL.

If you want newer than that you could possibly convince PyPy to build RPMs with 
COPR. I’m doing that for python-pip and co and it’s not very hard once you have 
the RPM spec file originally written, which could probably just be taken from 
Fedora.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing Python 2.6 Support after Twisted 15.1

[exarkun]

On 18 Mar, 10:45 am, hawk...@atleastfornow.net wrote:

Hi,

As Python 2.6 has been officially abandoned for a year+ (and will 
receive no further official security updates) and Python 2.7 has been 
available for almost five years, it might be time to put Python 2.6 
support to bed. The only currently supported distro that has Python 2.6 
is RHEL6, and RHEL7 with Python 2.7 has now been out for a year.


This would be in line with other major projects (eg. Django, Plone) and 
Python's porting guide (https://docs.python.org/3/howto/pyporting.html 
#drop-support-for-python-2-6-and-older). We can also remove some things 
from TestCase, and there's random smatterings of 2.6 support 
workarounds/comments that we could also remove.


As such, I think we should make 15.1 the final release which officially 
supports Python 2.6.


Any objections?


Please keep in mind that the way Twisted drops support for various 
platforms is by:


 1) announcing that it will be so
 2) removing the BuildBot configurations that demonstrate Twisted works 
on those platforms
 3) dropping the development/review requirement that the test suite be 
kept passing on those platforms


Contrast this with another possible meaning of "drop support" which is 
*not* what Twisted does:


 1) actively prioritize a bunch of work to make sure that Twisted 
definitely will be as broken as possible on the de-supported platform


Thanks.
Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] __nonzero__ for Deferred

[exarkun]

On 18 Mar, 10:03 pm, gl...@twistedmatrix.com wrote:
I'd like to deprecate and remove __nonzero__ on Deferreds. 
Occasionally I see code where someone (maybe even me) does "if d:" 
where they should have been doing "@d.addCallback def cb(result): if 
result: ...".


Anybody else have this issue?  Objections?


Er.  What?  It's a little early for april fools' day, isn't it?

Seriously, this is weird.  Am I missing something?

Can expand on what it would mean to deprecated a special method of a 
class that doesn't even define it and what makes Deferred unique among 
all user-defined classes in this regard.


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] __nonzero__ for Deferred

[Tristan Seligmann]

On 19 March 2015 at 00:03, Glyph Lefkowitz  wrote:
> I'd like to deprecate and remove __nonzero__ on Deferreds.

By "remove" do you mean "add an implementation that raises an
exception"? (It seems like this must be what you meant, I just wanted
to be clear since this is a slightly subtle issue)

I'm not sure offhand if I have any code that would be affected by
this, but I don't think I would have a problem considering any such
code incorrect. The most likely case I can think of is where I've
lazily written something like "if d" instead of "if d is not None".

That is to say, "+1".
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python