Re: [Python-Dev] Committing PEP 3155

2013-12-13 Thread Kingmody 


‏‫من جهاز الـ iPad الخاص بي‬___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Committing PEP 3155

2013-12-13 Thread Kingmody 


‏‫من جهاز الـ iPad الخاص بي‬___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Committing PEP 3155

2013-12-13 Thread Kingmody 


‏‫من جهاز الـ iPad الخاص بي‬___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How do we feel about using pragmas and __attribute__ in C code?

2013-12-13 Thread Brett Cannon 
http://bugs.python.org/issue12837 deals with the single compiler warning
left on OS X: a tautalogical compare in socketmodule.c that is valid under
POSIX. I have a solution that uses pragmas to turn off tautological compare
warnings for the single 'if' statement that triggers it. But there are very
few places in Python's code base which use pragmas and I have never seen a
discussion if we are okay with their overall use.

So is there any reason to not use pragmas sparsely in the code?

Tying into this and using compiler-specific things in C code, what about
__attribute__? http://bugs.python.org/issue19298 proposes an idea that
Daniel Stutzbach originally came up with where we could use __atribute__
(behind a nicer macro) to help detect refleaks on PyObject* stack
variables. Would __attribute__ usage be okay in that situation?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2013-12-13 Thread Python tracker 

ACTIVITY SUMMARY (2013-12-06 - 2013-12-13)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4322 ( -1)
  closed 27428 (+69)
  total  31750 (+68)

Open issues with patches: 1979 


Issues opened (48)
==

#16669: Docstrings for namedtuple
http://bugs.python.org/issue16669  reopened by serhiy.storchaka

#19911: ntpath.splitdrive() fails when UNC part contains \u0130
http://bugs.python.org/issue19911  opened by serhiy.storchaka

#19912: ntpath.splitunc() is broken and not tested
http://bugs.python.org/issue19912  opened by serhiy.storchaka

#19913: TR/Crypt.XPACK.Gen-4 in easy_install.exe
http://bugs.python.org/issue19913  opened by christian.heimes

#19914: help([object]) returns "Not enough memory." on standard Python
http://bugs.python.org/issue19914  opened by hct

#19915: int.bit_at(n) - Accessing a single bit in O(1)
http://bugs.python.org/issue19915  opened by anon

#19917: [httplib] logging information for request is not pretty printe
http://bugs.python.org/issue19917  opened by mcepl

#19918: PureWindowsPath.relative_to() is not case insensitive
http://bugs.python.org/issue19918  opened by serhiy.storchaka

#19919: SSL: test_connect_ex_error fails with EWOULDBLOCK
http://bugs.python.org/issue19919  opened by christian.heimes

#19920: TarFile.list() fails on some files
http://bugs.python.org/issue19920  opened by serhiy.storchaka

#19921: Path.mkdir(0, True) always fails
http://bugs.python.org/issue19921  opened by serhiy.storchaka

#19923: OSError: [Errno 512] Unknown error 512 in test_multiprocessing
http://bugs.python.org/issue19923  opened by pitrou

#19925: Add unit test for spwd module
http://bugs.python.org/issue19925  opened by vajrasky

#19927: Path-based loaders lack a meaningful __eq__() implementation.
http://bugs.python.org/issue19927  opened by eric.snow

#19930: os.makedirs('dir1/dir2', 0) always fails
http://bugs.python.org/issue19930  opened by serhiy.storchaka

#19931: namedtuple docstrings are verbose for no added benefit
http://bugs.python.org/issue19931  opened by nedbat

#19933: Round default argument for "ndigits"
http://bugs.python.org/issue19933  opened by JBernardo

#19934: collections.Counter.most_common does not document `None` as ac
http://bugs.python.org/issue19934  opened by mgilson

#19936: Executable permissions of Python source files
http://bugs.python.org/issue19936  opened by serhiy.storchaka

#19938: Re-enable test_bug_1333982 on 3.x
http://bugs.python.org/issue19938  opened by zach.ware

#19939: Deprecate portions or all of pkgutil module.
http://bugs.python.org/issue19939  opened by eric.snow

#19940: ssl.cert_time_to_seconds() returns wrong results if local time
http://bugs.python.org/issue19940  opened by akira

#19941: python -m imports non-ASCII .py file without encoding declarat
http://bugs.python.org/issue19941  opened by jwilk

#19942: UTF-8 encoding not enforced
http://bugs.python.org/issue19942  opened by jwilk

#19944: Make importlib.find_spec load packages as needed
http://bugs.python.org/issue19944  opened by ncoghlan

#19948: POSIX semantics of PATH search in execvpe is not respected
http://bugs.python.org/issue19948  opened by glondu

#19949: Explicitly skip or mask skipped/disabled tests in test_xpickle
http://bugs.python.org/issue19949  opened by zach.ware

#19950: Document that unittest.TestCase.__init__ is called once per te
http://bugs.python.org/issue19950  opened by Claudiu.Popa

#19953: __iadd__() doc not strictly correct
http://bugs.python.org/issue19953  opened by ferno

#19954: test_tk floating point exception on my gentoo box running tk 8
http://bugs.python.org/issue19954  opened by r.david.murray

#19955: When adding .PY and .PYW to PATHEXT, it replaced string instea
http://bugs.python.org/issue19955  opened by nickhil.rokkam

#19956: inspect.getsource(obj.foo) fails when foo is an injected metho
http://bugs.python.org/issue19956  opened by mtahmed

#19959: argparse.FileType does not expand tilde "~"
http://bugs.python.org/issue19959  opened by garthy

#19960: MacOSX: Building 2.7 without the xcode command line  tools ins
http://bugs.python.org/issue19960  opened by ronaldoussoren

#19961: MacOSX: Tkinter build failure when building without command-li
http://bugs.python.org/issue19961  opened by ronaldoussoren

#19962: Create a 'python.bat' script to invoke interpreter from source
http://bugs.python.org/issue19962  opened by zach.ware

#19963: Update docs for importlib.import_module()
http://bugs.python.org/issue19963  opened by brett.cannon

#19965: Non-atomic generation of Include/Python-ast.h and Python/Pytho
http://bugs.python.org/issue19965  opened by Arfrever

#19966: Wrong mtimes of files in 3.3.3 tarballs
http://bugs.python.org/issue19966  opened by Arfrever

#19967: asyncio: remove _TracebackLogger
http://bugs.python.org/issue19967  opened by haypo

#19968: Using DESTDIR breaks

Re: [Python-Dev] How do we feel about using pragmas and __attribute__ in C code?

2013-12-13 Thread Stefan Krah 
Brett Cannon  wrote:
> So is there any reason to not use pragmas sparsely in the code?

I'm +1 on using pragmas for suppressing selected warnings.


> Tying into this and using compiler-specific things in C code, what about
> __attribute__? http://bugs.python.org/issue19298 proposes an idea that Daniel
> Stutzbach originally came up with where we could use __atribute__ (behind a
> nicer macro) to help detect refleaks on PyObject* stack variables. Would
> __attribute__ usage be okay in that situation?

I would have to see an example function, mostly to get an idea of how
readable the code is.


Stefan Krah


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we feel about using pragmas and __attribute__ in C code?

2013-12-13 Thread Christian Heimes 
Am 13.12.2013 18:04, schrieb Brett Cannon:
> http://bugs.python.org/issue12837 deals with the single compiler warning
> left on OS X: a tautalogical compare in socketmodule.c that is valid
> under POSIX. I have a solution that uses pragmas to turn off
> tautological compare warnings for the single 'if' statement that
> triggers it. But there are very few places in Python's code base which
> use pragmas and I have never seen a discussion if we are okay with their
> overall use.

+1

We should aim for zero compiler warnings. You may have to wrap the
pragma in a #ifdef __clang__ block to silence warnings:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/830/steps/compile/logs/warnings%20%2822%29

> Tying into this and using compiler-specific things in C code, what about
> __attribute__? http://bugs.python.org/issue19298 proposes an idea that
> Daniel Stutzbach originally came up with where we could use __atribute__
> (behind a nicer macro) to help detect refleaks on PyObject* stack
> variables. Would __attribute__ usage be okay in that situation?

+1, too.

Christian

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

2013-12-13 Thread Alexander Belopolsky 
On Fri, Nov 15, 2013 at 9:10 PM, Tim Peters  wrote:

> > _DI4Y   = _days_before_year(5)
> > # A 4-year cycle has an extra leap day over what we'd get from pasting
> > # together 4 single years.
> > assert _DI4Y == 4 * 365 + 1
> >
> > To me, the constant should be directly set to its known value.
> > _DI4Y = 4*365 + 1.
> > The function should then be tested in test_datetime.
> >   self.assertEqual(dt._days_before_year(5), dt._DI4Y)
>
> I think making that change would be pointless code churn.  Harmful,
> even.  As the guy who happened to have written that code ;-), I think
> it's valuable to have the _code_ (not off buried in some monstrously
> tedious test file) explain what the comments there do explain, and
> verify with the assert.  If anyone needs to muck with the
> implementation of datetime, it's crucial they understand what DI4Y
> _means_, and that it's identical to _days_before_year(5).  Its actual
> value (4*365 + 1) isn't really interesting.  Defining _DI4Y _as_
> _days_before_year(5) captures its _meaning_.
>


Interestingly, the corresponding C code is closer to what Terry suggested:

/* Number of days in 4, 100, and 400 year cycles.  That these have
 * the correct values is asserted in the module init function.
 */
#define DI4Y1461/* days_before_year(5); days in 4 years */
#define DI100Y  36524   /* days_before_year(101); days in 100 years */
#define DI400Y  146097  /* days_before_year(401); days in 400 years  */
...  skipping to the init function ...
/* A 4-year cycle has an extra leap day over what we'd get from
 * pasting together 4 single years.
 */
assert(DI4Y == 4 * 365 + 1);
assert(DI4Y == days_before_year(4+1));

This is probably explainable by the limitations of the C language, but I
would find

_DI4Y = 4 * 365 + 1
assert _DI4Y == _days_before_year(5)

to be more natural than the way it is currently written.


>
> Ain't broke - don't fix.


Agree.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

2013-12-13 Thread Vajrasky Kok 
Greetings,

When fixing/adding error message for wrong type of argument in C code,
I am always confused, how long the wrong type is the ideal?

The type of error message that I am talking about:

"Blabla() argument 1 must be integer not wrong_type".

We have inconsistency in CPython code, for example:

Python/sysmodule.c
===
PyErr_Format(PyExc_TypeError,
"can't intern %.400s", s->ob_type->tp_name);

Modules/_json.c

PyErr_Format(PyExc_TypeError,
 "first argument must be a string, not %.80s",
 Py_TYPE(pystr)->tp_name);


Objects/typeobject.c
===
PyErr_Format(PyExc_TypeError,
 "can only assign string to %s.__name__, not '%s'",
 type->tp_name, Py_TYPE(value)->tp_name);

So is it %.400s or %.80s or %s? I vote for %s.

Other thing is which one is more preferable? Py_TYPE(value)->tp_name
or value->ob_type->tp_name? I vote for Py_TYPE(value)->tp_name.

Or this is just a matter of taste?

Thank you.

Vajrasky Kok
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

2013-12-13 Thread David Hutto 
Being that python is, to me, a prototyping language, then every possible
outcome should be presented to the end user.

A full variety of explanations should be presented to the programmer.



On Fri, Dec 13, 2013 at 11:56 PM, Vajrasky Kok
wrote:

> Greetings,
>
> When fixing/adding error message for wrong type of argument in C code,
> I am always confused, how long the wrong type is the ideal?
>
> The type of error message that I am talking about:
>
> "Blabla() argument 1 must be integer not wrong_type".
>
> We have inconsistency in CPython code, for example:
>
> Python/sysmodule.c
> ===
> PyErr_Format(PyExc_TypeError,
> "can't intern %.400s", s->ob_type->tp_name);
>
> Modules/_json.c
> 
> PyErr_Format(PyExc_TypeError,
>  "first argument must be a string, not %.80s",
>  Py_TYPE(pystr)->tp_name);
>
>
> Objects/typeobject.c
> ===
> PyErr_Format(PyExc_TypeError,
>  "can only assign string to %s.__name__, not '%s'",
>  type->tp_name, Py_TYPE(value)->tp_name);
>
> So is it %.400s or %.80s or %s? I vote for %s.
>
> Other thing is which one is more preferable? Py_TYPE(value)->tp_name
> or value->ob_type->tp_name? I vote for Py_TYPE(value)->tp_name.
>
> Or this is just a matter of taste?
>
> Thank you.
>
> Vajrasky Kok
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com *
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com