How Enum items should be pickled, by value or by name?
I think that Enum will be used to collect system-depending constants, so
the value of AddressFamily.AF_UNIX can be 1 on one platform and 2 on
other. If pickle enums by value, then pickled AddressFamily.AF_INET on
on platform can be unpickled as AddressFamily.AF_UNIX on other platform.
This looks weird and contrary to the nature of enums.
On Mon, Feb 17, 2014 at 6:36 PM, victor.stinner
<python-checkins(a)python.org> wrote:
> http://hg.python.org/cpython/rev/79ccf36b0fd0
> changeset: 89239:79ccf36b0fd0
> user: Victor Stinner <victor.stinner(a)gmail.com>
> date: Tue Feb 18 01:35:40 2014 +0100
> summary:
> Close #20656: Fix select.select() on OpenBSD 64-bit
>
> files:
> Modules/selectmodule.c | 22 ++++++++++++----------
> 1 files changed, 12 insertions(+), 10 deletions(-)
This changeset caused a compile warning on 32-bit Windows:
..\Modules\selectmodule.c(238): warning C4244: '=' : conversion from
'time_t' to 'long', possible loss of data
[P:\ath\to\cpython\PCbuild\select.vcxproj]
> diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c
> --- a/Modules/selectmodule.c
> +++ b/Modules/selectmodule.c
> @@ -212,11 +212,18 @@
> return NULL;
> }
> else {
> -#ifdef MS_WINDOWS
> + /* On OpenBSD 5.4, timeval.tv_sec is a long.
> + * Example: long is 64-bit, whereas time_t is 32-bit. */
> time_t sec;
> - if (_PyTime_ObjectToTimeval(tout, &sec, &tv.tv_usec,
> + /* On OS X 64-bit, timeval.tv_usec is an int (and thus still 4
> + bytes as required), but no longer defined by a long. */
> + long usec;
> + if (_PyTime_ObjectToTimeval(tout, &sec, &usec,
> _PyTime_ROUND_UP) == -1)
> return NULL;
> +#ifdef MS_WINDOWS
> + /* On Windows, timeval.tv_sec is a long (32 bit),
> + * whereas time_t can be 64-bit. */
> assert(sizeof(tv.tv_sec) == sizeof(long));
> #if SIZEOF_TIME_T > SIZEOF_LONG
> if (sec > LONG_MAX) {
> @@ -225,16 +232,11 @@
> return NULL;
> }
> #endif
> - tv.tv_sec = (long)sec;
> #else
> - /* 64-bit OS X has struct timeval.tv_usec as an int (and thus still 4
> - bytes as required), but no longer defined by a long. */
> - long tv_usec;
> - if (_PyTime_ObjectToTimeval(tout, &tv.tv_sec, &tv_usec,
> - _PyTime_ROUND_UP) == -1)
> - return NULL;
> - tv.tv_usec = tv_usec;
> + assert(sizeof(tv.tv_sec) >= sizeof(sec));
> #endif
> + tv.tv_sec = sec;
This is the offending line.
I'm not sure how best to fix it, so I'm just pointing it out :)
--
Zach
In article <3fRhkW2rDjz7LmY(a)mail.python.org>,
georg.brandl <python-checkins(a)python.org> wrote:
> http://hg.python.org/cpython/rev/eef7899ea7ab
> changeset: 89212:eef7899ea7ab
> user: Georg Brandl <georg(a)python.org>
> date: Sun Feb 16 09:46:36 2014 +0100
> summary:
> Doc: do not rely on checked-out Sphinx toolchain from svn.python.org
> anymore
>
> Nowadays it is likely that people will have Sphinx installed,
> and if not, they will know how to install it.
>
> This also simplifies life a lot for distribution packagers,
> who typically do not want the doc build process to connect
> to external web resources.
This checkin breaks the OS X installer builds, see for instance:
http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513
I've opened Issue20644 to address updating the OS X installer build
process and buildbot to deal with this change. I imagine it also
affects the Windows installer build. This change should not be
cherry-picked into 3.4.x until these issues are addressed.
--
Ned Deily,
nad(a)acm.org
Can someone please take a look at http://bugs.python.org/issue20621
for me? It appears that there is a significant problem with zipimport
in 3.3.4. It's causing breakage in virtualenv but I've isolated the
issue to what I think is Python itself.
Basically, until this bug is fixed, virtualenv won't work on Windows
with Python 3.3.4, as far as I can tell.
Thanks,
Paul
It appears there's no obvious link from bugs.python.org to the contributor
agreement - you need to go via the unintuitive link Foundation ->
Contribution Forms (and from what I've read, you're prompted when you add a
patch to the tracker).
I'd suggest that if the "Contributor Form Received" field is "No" in user
details, there be a link to http://www.python.org/psf/contrib/.
Tim Delaney
Dear friends,
This is related with ticket 19717: "resolve() fails when the path
doesn't exist".
Assuming /home/cutecat exists but not /home/cutecat/aa,
what is the desired output of
Path('/home/cutecat/aa/bb/cc').resolve(strict=False)?
Should it be:
"/home/cutecat" (the existed path only),
"/home/cutecat/aa" (the first non-existed path; my current strategy), or
"/home/cutecat/aa/bb/cc" (the default behaviour of os.path.realpath)?
Vajrasky
Many Python tests were written a very long time before the unittest,
using simple asserts. Then, when they have been ported to the unittest,
asserts were replaced with the assert_ method and then with assertTrue.
The unittest has a number of other methods to check for and report
failure, from assertEqual, to more specific assertIs, assertIn,
assertIsInstance, etc, added in 2.7. New methods provide better
reporting in case of failure.
I wrote a large patch which modifies the tests to use more specific
methods [1]. Because it is too large, it was divided into many smaller
patches, and separate issues were opened for them. At the moment the
major part of the original patch has already been committed. Many thanks
to Ezio for making a review for the majority of the issues. Some changes
have been made by other people in unrelated issues.
Although Raymond approved a patch for test_bigmem [2], his expressed the
insistent recommendation not to do this. So I stop committing new
reviewed patches. Terry recommended to discuss this in Python-Dev. What
are your thoughts?
[1] http://bugs.python.org/issue16510
[2] http://bugs.python.org/issue20547
Hi,
Here, its Nitin Agarwal, an open source software developer and enthusiast.
Currently, I am pursuing Computer Science and Engineering at International
Institute of Information Technology, INDIA. I had an experience working
with
the open source organisations and development of open source software.
You can have a look at my github profile.[1] My first priority programming
languages
include GNU C/C++ and Python. I have been using these languages for the
Coding,
Programming challenges, Application development and contributing to open
source
software. Apart from this, I am also aware of version control systems
git/github, SVN,
bazaar and other web technologies like Javascript, Jinja templates, HTML,
CSS too.
I am ambititous person eager to learn other technologies when in need while
working.
You can have a look at my Wikipedia profile.[2]
My interests include Programming Languages, open source software
development,
networking concepts and system administration tasks.
While looking at the Project Ideas proposed by the mentors and developers
of the Python
Community, I found the Email Projects working to work for support of RFC
6532 in the
email package and support of RFC 6531 in the smtplib and/or smtpd.
I am willing to work on this project ideas as a prospective student in the
upcoming
Google Summer of Code 2014. I would like to discuss with the mentors more
about
the project in detail and would like to start off contributing to the
project early enough
so as to make a strong proposal for Gsoc 2014.
*Nitin Agarwal*
[1] https://github.com/NitinAgarwal
[2] https://en.wikipedia.org/wiki/User:Nitinagarwal3006
[3] IRC handle : nitinagarwal3006
