Re: [Python-Dev] test___all__ polluting sys.modules?

2012-12-31 Thread Arfrever Frehtes Taifersar Arahesis 
2012-12-30 15:48:30 R. David Murray napisał(a):
> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan  wrote:
> > However, specifically spinning out the "import the world" tests like
> > test_pydoc and test___all__ to a separate process might be worth the
> > effort.
> 
> Adding something to regertest (or unittest?) so that certain nominated
> test modules are run in a subprocess has been discussed previously, but
> so far no one has stepped up to implement it :) 

Actually patches have been implemented about 2 years ago, but nobody committed 
them.
http://bugs.python.org/issue1674555

> (I think this came up originally for test_site, but I don't remember for 
> sure.)

Yes, test_site.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.
___
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] BDFL delegate for Daniel Holth's packaging PEPs?

2012-12-31 Thread Antoine Pitrou 
On Mon, 31 Dec 2012 15:40:39 +1000
Nick Coghlan  wrote:
> Does anyone object to my naming myself as BDFL-Delegate for Daniel
> Holth's packaging PEPs?
> 
> PEP 425  Compatibility Tags for Built Distributions
> PEP 426  Metadata for Python Software Packages 1.3
> PEP 427  The Wheel Binary Package Format 0.1
> 
> I've mentioned doing so before, but IIRC it was in the depths of a
> larger thread, so I figured I should make a separate post before
> claiming them in the PEPs repo.

Ok for me. It would be nice if one of the past disutils maintainers
gave their approval too, but they don't seem very active.

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] BDFL delegate for Daniel Holth's packaging PEPs?

2012-12-31 Thread Tarek Ziadé 

On 12/31/12 12:44 PM, Antoine Pitrou wrote:

On Mon, 31 Dec 2012 15:40:39 +1000
Nick Coghlan  wrote:

Does anyone object to my naming myself as BDFL-Delegate for Daniel
Holth's packaging PEPs?

PEP 425  Compatibility Tags for Built Distributions
PEP 426  Metadata for Python Software Packages 1.3
PEP 427  The Wheel Binary Package Format 0.1

I've mentioned doing so before, but IIRC it was in the depths of a
larger thread, so I figured I should make a separate post before
claiming them in the PEPs repo.

Ok for me. It would be nice if one of the past disutils maintainers
gave their approval too, but they don't seem very active.

FWIW I think Nick is perfect for this job.

Cheers
Tarek

--
Tarek Ziadé · http://ziade.org · @tarek_ziade

___
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] BDFL delegate for Daniel Holth's packaging PEPs?

2012-12-31 Thread Antoine Pitrou 
On Mon, 31 Dec 2012 13:36:23 +0100
Tarek Ziadé  wrote:
> On 12/31/12 12:44 PM, Antoine Pitrou wrote:
> > On Mon, 31 Dec 2012 15:40:39 +1000
> > Nick Coghlan  wrote:
> >> Does anyone object to my naming myself as BDFL-Delegate for Daniel
> >> Holth's packaging PEPs?
> >>
> >> PEP 425  Compatibility Tags for Built Distributions
> >> PEP 426  Metadata for Python Software Packages 1.3
> >> PEP 427  The Wheel Binary Package Format 0.1
> >>
> >> I've mentioned doing so before, but IIRC it was in the depths of a
> >> larger thread, so I figured I should make a separate post before
> >> claiming them in the PEPs repo.
> > Ok for me. It would be nice if one of the past disutils maintainers
> > gave their approval too, but they don't seem very active.
> FWIW I think Nick is perfect for this job.

I meant approval for the PEP, not for Nick :)


___
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] Draft PEP for time zone support.

2012-12-31 Thread Lennart Regebro 
On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano wrote:

> If I've understood it correctly, that contradicts the PEP. One example
> given is "Etc/GMT+11", which is not a timezone *name*, but a timezone
> name *plus an offset*. Presumably if GMT+11 is legal, so should be
> GMT+10:30.
>

This depends on your definition of a timezone name. There is no generally
accepted authority for time zone names, the closest one we get is the
zoneinfo database itself, which is maintained by ICANN. It has an
Etc/GMT+11.

There is no "Etc/GMT+11" named here:
>
> http://en.wikipedia.org/wiki/**List_of_tz_database_time_zones
>

It exists in the database files, http://www.iana.org/time-zones, the
``etcetera`` file.


> nor is it included in /usr/share/zoneinfo/zone.tab in either of the systems
>

zone.tab contains none of the Etc/Something zones.


> I looked at (one Debian, one Centos), but there is Etc/GMT. So I conclude
> that the PEP allows timezone rules, not just names.
>

This is more problematic, and for that reason I'll change the PEP to use
another example.


> Either way, I think the PEP needs to clarify what counts as a valid name
> string.


A timezone file that exists in the zoneinfo database used.

Perhaps the database is out-of-date, or the government has suddenly declared
> a daylight savings change that isn't reflected yet in the database. Or you
> want to set your own TZ rules for testing. Or you've just declared
> independence
> from the central government and are setting up your own TZ rules.
>
> time.tzset supports rules as well as names. Is there some reason why this
> module should not do the same?
>

You will be able to make your own rules, the simplest is probably by adding
it to your zoneinfo database. Doing so is however not trivial, and outside
of the scope of this PEP.

//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] PEP 431 Time zone support improvements - Update

2012-12-31 Thread Lennart Regebro 
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren wrote:

> The module could be split into several modules in a package without
> affecting the public API if that would help with maintenance, simular to
> unittest.
>

This is of course true. Maybe that is a good idea.

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

[Python-Dev] FYI: don't CC the peps mailing list

2012-12-31 Thread Brett Cannon 
Since this has happened for the second time in the past month, I want to
prevent a trend from starting here. Please do not CC the peps mailing list
on any discussions as it makes it impossible to know what emails are about
an actual update vs. people replying to some discussion which in no way
affects the PEP editors. Emails to the peps list should deal only with
adding/updating peps and only between the PEP editors and PEP authors.

Lennart, I tossed all emails that got held up in moderation, so please
check that the latest version of your PEP is in as you want, else send a
patch to the peps list directly (inlined text is not as easy to work with).
___
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] BDFL delegate for Daniel Holth's packaging PEPs?

2012-12-31 Thread R. David Murray 
On Mon, 31 Dec 2012 13:51:08 +0100, Antoine Pitrou  wrote:
> On Mon, 31 Dec 2012 13:36:23 +0100
> Tarek Ziadé  wrote:
> > On 12/31/12 12:44 PM, Antoine Pitrou wrote:
> > > On Mon, 31 Dec 2012 15:40:39 +1000
> > > Nick Coghlan  wrote:
> > >> Does anyone object to my naming myself as BDFL-Delegate for Daniel
> > >> Holth's packaging PEPs?
> > >>
> > >> PEP 425  Compatibility Tags for Built Distributions
> > >> PEP 426  Metadata for Python Software Packages 1.3
> > >> PEP 427  The Wheel Binary Package Format 0.1
> > >>
> > >> I've mentioned doing so before, but IIRC it was in the depths of a
> > >> larger thread, so I figured I should make a separate post before
> > >> claiming them in the PEPs repo.
> > > Ok for me. It would be nice if one of the past disutils maintainers
> > > gave their approval too, but they don't seem very active.
> > FWIW I think Nick is perfect for this job.
> 
> I meant approval for the PEP, not for Nick :)

Well, if Nick is "perfect" for the job, this amounts to the almost the
same thing :)

--David
___
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] [Python-checkins] peps: Further PEP 432 updates

2012-12-31 Thread Brett Cannon 
On Sun, Dec 30, 2012 at 8:39 AM, nick.coghlan wrote:

> [SNIP]
>  The ``-E`` command line option allows all environment variables to be
> -ignored when initialising the Python interpreter. An embedding application
> +ignored when initializing the Python interpreter. An embedding application
>  can enable this behaviour by setting ``Py_IgnoreEnvironmentFlag`` before
>  calling ``Py_Initialize()``.
>
>  In the CPython source code, the ``Py_GETENV`` macro implicitly checks this
>  flag, and always produces ``NULL`` if it is set.
>
> +
>  
>
>
That is true and that is a bug. =)

http://bugs.python.org/issue16826
___
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] Fwd: Broken links on http://www.python.org/download/mac/tcltk/#activetcl-8-5-11

2012-12-31 Thread Michael Foord 
There's a problem with the instructions for using Active TCL with Python for 
the Mac. 

Michael

Begin forwarded message:

> From: "Dr. Anthony G. Francis, Jr." 
> Subject: Broken links on 
> http://www.python.org/download/mac/tcltk/#activetcl-8-5-11
> Date: 19 December 2012 22:08:02 GMT
> To: webmas...@python.org
> 
> Hey gang,
> 
> The Python install instructions for Tck/TK appear to be out of date:
> 
> http://www.python.org/download/mac/tcltk/#activetcl-8-5-11
> As of this writing, there are two known serious problems with the most recent 
> ActivelTcl 8.5 releases for Mac OS X, 8.5.12 and 8.5.12.1. (See Issues #15574 
> and #15853 for more information.) Until these issues are resolved, use the 
> previous release of ActiveTcl, 8.5.11.1, which is available for download 
> here. This is an Aqua Cocoa Tk.
> 
> But the "download here" link is borken:
> 
> http://downloads.activestate.com/ActiveTcl/releases/8.5.11.1/
> Not Found
> The requested URL /ActiveTcl/releases/8.5.11.1/ was not found on this server.
> Apache/2.2.3 (CentOS) Server at downloads.activestate.com Port 80
> 
> As it so turns out, this is on purpose on ActiveState's part:
> 
> http://www.activestate.com/activetcl/downloads
> Looking for access to older versions of ActiveTcl?
> Community Edition offers access to the newest versions of ActiveTcl.
> Access to older versions is available in Business Edition and Enterprise 
> Edition.
> 
> Business edition is a thousand bucks a pop ( 
> http://www.activestate.com/business-edition ) so I has a bit of a sad - I was 
> just trying to run a quick experiment and have dived down a rabbit hole. It 
> appears also that ActiveTcl has gone beyond the buggy edition listed on the 
> Python.org tcltk page, so I'm going to give that a try.
> 
> -Anthony
> -- 
> Dr. Anthony G. Francis, Jr. ~ Renaissance Engineer ~ 408 221 7894
> cent...@dresan.com ~ www.fanufiku.com ~ www.dakotafrost.com


--
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] BDFL delegate for Daniel Holth's packaging PEPs?

2012-12-31 Thread Nick Coghlan 
On Mon, Dec 31, 2012 at 10:36 PM, Tarek Ziadé  wrote:
> On 12/31/12 12:44 PM, Antoine Pitrou wrote:
>>
>> On Mon, 31 Dec 2012 15:40:39 +1000
>> Nick Coghlan  wrote:
>>>
>>> Does anyone object to my naming myself as BDFL-Delegate for Daniel
>>> Holth's packaging PEPs?
>>>
>>> PEP 425  Compatibility Tags for Built Distributions
>>> PEP 426  Metadata for Python Software Packages 1.3
>>> PEP 427  The Wheel Binary Package Format 0.1
>>>
>>> I've mentioned doing so before, but IIRC it was in the depths of a
>>> larger thread, so I figured I should make a separate post before
>>> claiming them in the PEPs repo.
>>
>> Ok for me. It would be nice if one of the past disutils maintainers
>> gave their approval too, but they don't seem very active.
>
> FWIW I think Nick is perfect for this job.

Picking the other people they want a +1 from before giving their own
approval is one of the privileges of BDFL delegation, and indeed I'd
include Tarek and/or Éric in my list for these ones :)

I'll update the PEPs accordingly.

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] test___all__ polluting sys.modules?

2012-12-31 Thread Eli Bendersky 
On Mon, Dec 31, 2012 at 1:45 AM, Arfrever Frehtes Taifersar Arahesis <
arfrever@gmail.com> wrote:

> 2012-12-30 15:48:30 R. David Murray napisał(a):
> > On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan 
> wrote:
> > > However, specifically spinning out the "import the world" tests like
> > > test_pydoc and test___all__ to a separate process might be worth the
> > > effort.
> >
> > Adding something to regertest (or unittest?) so that certain nominated
> > test modules are run in a subprocess has been discussed previously, but
> > so far no one has stepped up to implement it :)
>
> Actually patches have been implemented about 2 years ago, but nobody
> committed them.
> http://bugs.python.org/issue1674555
>
> > (I think this came up originally for test_site, but I don't remember for
> sure.)
>
> Yes, test_site.
>

Thank you Arfrever. I'll take a look at those patches.
Eli
___
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] test___all__ polluting sys.modules?

2012-12-31 Thread Richard Oudkerk 

On 30/12/2012 9:52pm, Antoine Pitrou wrote:

If you have an object with a __del__ method as a module global, the
cyclic gc will refuse to consider the module globals at all (which
means it will affect unrelated objects).

So, yes, I think the shutdown purge is still necessary. Perhaps there
are ways to make it smarter.


With my earlier suggestion a module deleted from sys.modules before 
shutdown can have an unreclaimable global dict (if it contains a global 
with a __del__ method).


Perhaps, instead, modules could use a weakrefable subclass of dict for 
their globals dicts.  The module destructor could save the global dicts 
of deleted modules in a registry.  At shutdown any remaining globals 
dicts can be purged.


--
Richard

___
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] Fwd: Broken links on http://www.python.org/download/mac/tcltk/#activetcl-8-5-11

2012-12-31 Thread Ned Deily 
In article <5702d9ff-5a6a-4131-a093-1054155d4...@voidspace.org.uk>,
 Michael Foord  wrote:
> There's a problem with the instructions for using Active TCL with Python for 
> the Mac. 

No longer an issue: I updated the web page on 12-26:

Revision history
   €  2012-12-26 - updated for ActiveTcl 8.5.13 and Issue 15853 patch 
installer

-- 
 Ned Deily,
 n...@acm.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] test___all__ polluting sys.modules?

2012-12-31 Thread Gregory P. Smith 
On Sun, Dec 30, 2012 at 5:33 AM, Eli Bendersky  wrote:
>
>
> On Sat, Dec 29, 2012 at 5:34 PM, Nick Coghlan  wrote:
>
>> On Sun, Dec 30, 2012 at 10:46 AM, Benjamin Peterson 
>> wrote:
>> > 2012/12/29 Eli Bendersky :
>> >> Hi,
>> >>
>> >> This came up while investigating some test-order-dependency failures in
>> >> issue 16076.
>> >>
>> >> test___all__ goes over modules that have `__all__` in them and does
>> 'from
>> >>  import *' on them. This leaves a lot of modules in
>> sys.modules,
>> >> which may interfere with some tests that do fancy things with
>> sys,modules.
>> >> In particular, the ElementTree tests have trouble with it because they
>> >> carefully set up the imports to get the C or the Python version of
>> etree
>> >> (see issues 15083 and 15075).
>> >>
>> >> Would it make sense to save the sys.modules state and restore it in
>> >> test___all__ so that sys.modules isn't affected by this test?
>> >
>> > Sounds reasonable to me.
>>
>> I've tried this as an inherent property of regrtest before (to resolve
>> some problems with test_pydoc), and it didn't work - we have too many
>> modules with non-local side effects (IIRC, mostly related to the copy
>> and pickle registries).
>>
>> Given that it checks the whole standard library, test___all__ is
>> likely to run into the same problem.
>>
>>
> Yes, I'm running into all kinds of weird problems when saving/restoring
> sys.modules around test___all__. This is not the first time I get to fight
> this test-run-dependency problem and it's very frustrating.
>
> This may be a naive question, but why don't we run the tests in separate
> interpreters? For example with -j  we do (which creates all kinds of
> strange intermittent problems depending on which tests got bundled into the
> same process). Is this a matter of performance? Because that would help get
> rid of these dependencies between tests, which would probably save core
> devs some work and headache.
>

For test___all__ having it run itself within a subprocess to guarantee it
is in its own interpreter is wise.

Doing that for all tests by default though is a good way to hide problems
with particular tests and underhandedly encourage more bad behavior from
tests messing up the global environment as there are no consequences. We
should aim to keep our tests as clean as possible. That doesn't mean that
they _are_ (we've got a _lot_ of old messy code) but it is a good goal.

-gps


>
> After all, since a lot of the interpreter state is global (for example
> sys.modules), does it not make sense to run each test in a clean
> environment? Many tests do fancy things with the global environment which
> makes them difficult to keep clean and separate.
>
>
>> Hence test.support.import_fresh_module - it can ensure you get the
>> module you want, regardless of the preexisting contents of
>> sys.modules. (
>> http://docs.python.org/dev/library/test#test.support.import_fresh_module)
>>
>
>  Yes, this is the solution currently used in test_xml_etree. However,
> once pickling tests are added things stop working. Pickle uses __import__
> to import the module a class belongs to, bypassing all such trickery. So if
> test___all__ got _elementtree into sys.modules, pickle's __import__ finds
> it even if all the tests in test_xml_etree manage to ignore it for the
> Python version because they use import_fresh_module.
>
> Eli
>
>
>
> ___
> 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] test___all__ polluting sys.modules?

2012-12-31 Thread Gregory P. Smith 
On Sun, Dec 30, 2012 at 6:48 AM, R. David Murray wrote:

> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan 
> wrote:
> > On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky 
> wrote:
> > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah 
> wrote:
> > >>
> > >> Eli Bendersky  wrote:
> > >> > Yes, this is the solution currently used in test_xml_etree. However,
> > >> > once
> > >> > pickling tests are added things stop working. Pickle uses
> __import__ to
> > >> > import
> > >> > the module a class belongs to, bypassing all such trickery. So if
> > >> > test___all__
> > >> > got _elementtree into sys.modules, pickle's __import__ finds it
> even if
> > >> > all the
> > >> > tests in test_xml_etree manage to ignore it for the Python version
> > >> > because they
> > >> > use import_fresh_module.
> > >>
> > >> I ran into the same problem for test_decimal. The only thing that
> appears
> > >> to work is to set sys.modules['decimal'] explicitly before calling
> > >> dumps()/loads(). See:
> > >>
> > >>PythonAPItests.test_pickle()
> > >>ContextAPItests.test_pickle()
> > >
> > > Yes, this seems to have done the trick. Thanks for the suggestion.
> >
> > It may be worth offering a context manager/decorator equivalent to
> > "import_fresh_module".
>
> I suggested making import_fresh_module a context manager in the issue
> that Eli opened about test___all__.
>
> > > I'm still curious about the test-in-clean-env question though.
> >
> > As Stefan noted, the main advantage we get is that sometimes the
> > failure to clean up properly is in the standard lib code rather than
> > the tests, and with complete isolation we'd be less likely to notice
> > the problem.
> >
> > Once you combine that with the fact that rearchitecting regrtest to
> > work that way would be quite a bit of work, the motivation to make it
> > happen goes way down.
> >
> > However, specifically spinning out the "import the world" tests like
> > test_pydoc and test___all__ to a separate process might be worth the
> > effort.
>
> Adding something to regertest (or unittest?) so that certain nominated
> test modules are run in a subprocess has been discussed previously, but
> so far no one has stepped up to implement it :)  (I think this came up
> originally for test_site, but I don't remember for sure.)
>

test_subprocess and possibly a few others (things testing signal behavior,
etc) already have some individual tests that do this.  its pretty easy.
 subprocess.Popen of sys.executable typically with -E and the code either
in a string via -c or else point at a second file or add an argument for
main in the current file to detect.  making this simpler via something in
test.support might make sense if there is a common need for it.

-gps
___
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] Branch ancestry hiccup on the Mercurial repo

2012-12-31 Thread Antoine Pitrou 

Hello,

For the record, due to a bug in the "hg graft" command, a
recent changeset of mine basically merged branch 2.7 into 3.2:

$ hg log -r "ee8d999b6e05 or parents(ee8d999b6e05)" -G 
ochangeset:   81129:ee8d999b6e05
|\   branch:  3.2
| |  parent:  81124:e4ea38a92c4d
| |  parent:  81128:3436769a7964
| |  user:Antoine Pitrou 
| |  date:Fri Dec 28 19:07:43 2012 +0100
| |  summary: Forward port new test for SSLSocket.connect_ex()
| |
| o  changeset:   81128:3436769a7964
| |  branch:  2.7
| |  user:Antoine Pitrou 
| |  date:Fri Dec 28 19:03:43 2012 +0100
| |  summary: Backport Python 3.2 fix for issue #12065, and add
another test for SSLSocket.connect_ex().
| |
o |  changeset:   81124:e4ea38a92c4d
| |  branch:  3.2
| |  parent:  81118:b2cd12690a51
| |  user:Serhiy Storchaka 
| |  date:Fri Dec 28 09:42:11 2012 +0200
| |  summary: Issue #16761: Raise TypeError when int() called with
base argument only.
| |


The first symptoms were reported in
http://bz.selenic.com/show_bug.cgi?id=3748 but the actual cause of the
issue is http://bz.selenic.com/show_bug.cgi?id=3667.

Chances are the problem won't be very annoying in practice, but just
FYI.

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