Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Paul Moore]

On 12 February 2016 at 00:16, Steven D'Aprano  wrote:
> I think that there is broad agreement that:
>
> - the basic idea is sound
> - leading underscores followed by digits are currently legal
>   identifiers and this will not change
> - underscores should not follow the sign - +
> - underscores should not follow the decimal point .
> - underscores should not follow the exponent e|E
> - underscores will not be permitted inside the exponent (even if
>   it is harmless, it's silly to write 1.2e9_9)
> - underscores should not follow the complex suffix j
>
> and only minor disagreement about:
>
> - whether or not underscores will be allowed after the base
>   specifier 0x 0o 0b
> - whether or not underscores will be allowed before the decimal
>   point, exponent and complex suffix.
>
> Can we have a show of hands, in favour or against the above two? And
> then perhaps Guido can rule on this one way or the other and we can get
> back to arguing about more important matters? :-)
>
> In case it isn't obvious, I prefer to say No to allowing underscores
> after the base specifier, or before the decimal point, exponent and
> complex suffix.

I have no opinion on anything other than that whatever syntax is
implemented as long as it allows single underscores between digits,
such as

1_000_000

Everything else is irrelevant to me, and if I read code that uses
anything else, I'd judge it based on readability and style, and
wouldn't care about arguments that "it's allowed by the grammar".

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Py_SETREF again

[Serhiy Storchaka]

Sorry to bringing this up again. I was hoping we were done with that.

When discussing the name of the Py_SETREF macro I was supposed to add a 
pair of macros: for Py_DECREF and Py_XDECREF. But I got a lot of 
opinions to be limited to only one macro.


On 28.02.14 15:58, Kristján Valur Jónsson wrote:
> Also, for the equivalence to hold there is no separate Py_XSETREF, the X
> behaviour is implied, which I favour.  Enough of this X-proliferation
> already!

On 16.12.15 16:53, Random832 wrote:
> I think "SET" names imply that it's safe if the original
> reference is NULL. This isn't an objection to the names, but if
> it is given one of those names I think it should use Py_XDECREF.

It was my initial intension. But then I had got a number of voices for 
single macros.


On 16.12.15 23:16, Victor Stinner wrote:
> I would prefer a single macro to avoid bugs, I don't think that such
> macro has a critical impact on performances. It's more designed for
> safety, no?

On 17.12.15 08:22, Nick Coghlan wrote:
>> 1. Py_SETREF
>
> +1 if it always uses Py_XDECREF on the previous value (as I'd expect
> this to work even if the previous value was NULL)

There was no (besides my) clearly expressed vote for two macros.
As a result I have replaced both Py_DECREF and Py_XDECREF with the macro 
that always uses Py_XDECREF.


Now Raymond, who was not involved in the previous discussions, expressed 
the view that we should to rename Py_SETREF to Py_XSETREF and add new 
Py_SETREF that uses Py_DECREF for using in the code that used Py_DECREF 
previously. [1]


We should discuss the need for this, and may be re-discuss the names for 
the macros.


[1] http://bugs.python.org/issue26200

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

Re: [Python-Dev] Py_SETREF again

[Nick Coghlan]

On 12 February 2016 at 19:45, Serhiy Storchaka  wrote:
> Now Raymond, who was not involved in the previous discussions, expressed the
> view that we should to rename Py_SETREF to Py_XSETREF and add new Py_SETREF
> that uses Py_DECREF for using in the code that used Py_DECREF previously.
> [1]
>
> We should discuss the need for this, and may be re-discuss the names for the
> macros.

I'm inclined to go with the resolution discussed later in the comments
on that tracker issue - switch to spelling out the details when you
want to avoid the Py_XDECREF inside the Py_SETREF macro. As Raymond
notes, if you're wanting to manage when and how DECREF's occur, you
may not want to hide them inside another macro at all.

I'm also wondering if it may be worth adding some notes about
reference counting to PEP 7, such as:

* using Py_RETURN_NONE/FALSE/TRUE
* using Py_CLEAR
* using Py_SETREF (but being free to avoid it if you want to use
Py_DECREF instead or are hand-optimising the code in some other way)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

[Victor Stinner]

ping?

2016-02-08 15:18 GMT+01:00 Victor Stinner :
> 2016-02-04 15:05 GMT+01:00 M.-A. Lemburg :
>> Sometimes, yes, but we also do allocations for e.g.
>> parsing values in Python argument tuples (e.g. using
>> "es" or "et"):
>>
>> https://docs.python.org/3.6/c-api/arg.html
>>
>> We do document to use PyMem_Free() on those; not sure whether
>> everyone does this though.
>
> It's well documented. If programs start to crash, they must be fixed.
>
> I don't propose to "break the API" for free, but to get a speedup on
> the overall Python.
>
> And I don't think that we can say that it's an API change, since we
> already stated that PyMem_Free() must be used.
>
> If your program has bugs, you can use a debug build of Python 3.5 to
> detect misusage of the API.
>
>
>> The Python test suite doesn't test Python C extensions,
>> so it's not surprising that it passes :-)
>
> What do you mean by "C extensions"? Which modules?
>
> Many modules in the stdlib have "C accelerators" and the PEP 399 now
> *require* to test the C and Python implementations.
>
>
>
>>> Instead of teaching developers that well, in fact, PyObject_Malloc()
>>> is unrelated to object programming, I think that it's simpler to
>>> modify PyMem_Malloc() to reuse pymalloc ;-)
>>
>> Perhaps if you add some guards somewhere :-)
>
> We have runtime checks but only implemented in debug mode for efficiency.
>
> By the way, I proposed once to add an environment variable to allow to
> enable these checks without having to recompile Python.  Since the PEP
> 445, it became easy to implement this. What do you think?
> https://www.python.org/dev/peps/pep-0445/#add-a-new-pydebugmalloc-environment-variable
>
> "This alternative was rejected because a new environment variable
> would make Python initialization even more complex. PEP 432 tries to
> simplify the CPython startup sequence."
>
> The PEP 432 looks stuck, so I don't think that we should block
> enhancements because of this PEP. Anyway, my idea should be easy to
> implement.
>
>
>> Seriously, this may work if C extensions use the APIs
>> consistently, but in order to tell, we'd need to check
>> few.
>
> Can you suggest me names of projects that must be tested?
>
>
>> I guess the main question then is whether pymalloc is good enough
>> for general memory allocation needs; and the answer may well be
>> "yes".
>
> What do you mean by "good enough"? For the runtime performance,
> pymalloc looks to be faster than malloc(). What are your other
> criterias? Memory fragmentation?
>
>
> Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Time for a change of random number generator?

[Robert Kern]

On 2016-02-12 04:15, Tim Peters wrote:

[Greg Ewing ]

The Mersenne Twister is no longer regarded as quite state-of-the art
because it can get into states that produce long sequences that are
not very random.

There is a variation on MT called WELL that has better properties
in this regard. Does anyone think it would be a good idea to replace
MT with WELL as Python's default rng?


I don't think so, because I've seen no groundswell of discontent about
the Twister among Python users.  Perhaps I'm missing some?


Well me, but I'm mostly focused on numpy's PRNG, which is proceeding apace.

  https://github.com/bashtage/ng-numpy-randomstate

While I am concerned about MT's BigCrush failures, what makes me most 
discontented is not having multiple guaranteed-independent streams.



It's prudent to wait for someone else to find the early surprises in
PCG and Random123 too ;-)


Quite so!

--
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
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

[M.-A. Lemburg]

On 12.02.2016 12:18, Victor Stinner wrote:
> ping?

Sorry, your email must gotten lost in my inbox.

> 2016-02-08 15:18 GMT+01:00 Victor Stinner :
>> 2016-02-04 15:05 GMT+01:00 M.-A. Lemburg :
>>> Sometimes, yes, but we also do allocations for e.g.
>>> parsing values in Python argument tuples (e.g. using
>>> "es" or "et"):
>>>
>>> https://docs.python.org/3.6/c-api/arg.html
>>>
>>> We do document to use PyMem_Free() on those; not sure whether
>>> everyone does this though.
>>
>> It's well documented. If programs start to crash, they must be fixed.
>>
>> I don't propose to "break the API" for free, but to get a speedup on
>> the overall Python.
>>
>> And I don't think that we can say that it's an API change, since we
>> already stated that PyMem_Free() must be used.
>>
>> If your program has bugs, you can use a debug build of Python 3.5 to
>> detect misusage of the API.

Yes, but people don't necessarily do this, e.g. I have
for a very long time ignored debug builds completely
and when I started to try them, I found that some of the
things I had been doing with e.g. free list implementations
did not work in debug builds.

>>> The Python test suite doesn't test Python C extensions,
>>> so it's not surprising that it passes :-)
>>
>> What do you mean by "C extensions"? Which modules?
>>
>> Many modules in the stdlib have "C accelerators" and the PEP 399 now
>> *require* to test the C and Python implementations.

Yes, but those are part of the stdlib. You'd need to check
a few C extensions which are not tested as part of the stdlib,
e.g. numpy, scipy, lxml, pillow, etc. (esp. ones which implement custom
types in C since these will often need the memory management
APIs).

It may also be a good idea to check wrapper generators such
as cython, swig, cffi, etc.

 Instead of teaching developers that well, in fact, PyObject_Malloc()
 is unrelated to object programming, I think that it's simpler to
 modify PyMem_Malloc() to reuse pymalloc ;-)
>>>
>>> Perhaps if you add some guards somewhere :-)
>>
>> We have runtime checks but only implemented in debug mode for efficiency.
>>
>> By the way, I proposed once to add an environment variable to allow to
>> enable these checks without having to recompile Python.  Since the PEP
>> 445, it became easy to implement this. What do you think?
>> https://www.python.org/dev/peps/pep-0445/#add-a-new-pydebugmalloc-environment-variable
>>
>> "This alternative was rejected because a new environment variable
>> would make Python initialization even more complex. PEP 432 tries to
>> simplify the CPython startup sequence."
>>
>> The PEP 432 looks stuck, so I don't think that we should block
>> enhancements because of this PEP. Anyway, my idea should be easy to
>> implement.

I suppose such a flag would create a noticeable runtime
performance hit, since the compiler would no longer be
able to inline the PyMem_*() APIs if you redirect those
APIs to other sets at runtime.

I also don't see much point in carrying around such
baggage in production builds of Python, since you'd most
likely only want to use the tools to debug C extensions during
their development.

>>> Seriously, this may work if C extensions use the APIs
>>> consistently, but in order to tell, we'd need to check
>>> few.
>>
>> Can you suggest me names of projects that must be tested?

See above for a list of starters :-)

It would be good to add a few more that work on text or
larger chunks of memory, since those will most likely utilize
the memory allocators more than other extensions which mostly
wrap (sets of) C variables.

Some of them may also have benchmarks, so in addition to
checking whether they work with the change, you could also
test performance.

>>> I guess the main question then is whether pymalloc is good enough
>>> for general memory allocation needs; and the answer may well be
>>> "yes".
>>
>> What do you mean by "good enough"? For the runtime performance,
>> pymalloc looks to be faster than malloc(). What are your other
>> criterias? Memory fragmentation?

Runtime performance, difference in memory consumption (arenas
cannot be freed if there are still small chunks allocated),
memory locality. I'm no expert in this, so can't really
comment much.

I suspect that lib C and OS provided allocators will have
advantages as well, but since pymalloc redirects to them for
all larger memory chunks, it's probably an overall win for
Python C extensions (and Python itself).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 12 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/

2016-01-19: Released eGenix pyOpenSSL 0.13.13 ... http://egenix.com/go86

::: We implement business ideas - efficiently in both time and costs :::

Re: [Python-Dev] Py_SETREF again

[Georg Brandl]

On 02/12/2016 10:45 AM, Serhiy Storchaka wrote:
> Sorry to bringing this up again. I was hoping we were done with that.
> 
> When discussing the name of the Py_SETREF macro I was supposed to add a 
> pair of macros: for Py_DECREF and Py_XDECREF. But I got a lot of 
> opinions to be limited to only one macro.
>
> There was no (besides my) clearly expressed vote for two macros.

I would have voted in favor.

Spelling the SETREF out, as Nick proposes, kind of defies the purpose of
the macro: it's not strictly a convenience macro, it helps prevent
refcounting bugs.

> As a result I have replaced both Py_DECREF and Py_XDECREF with the macro 
> that always uses Py_XDECREF.

Can you roughly say which fraction of replacements changed DECREF to an
implicit XDECREF?

Georg

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

Re: [Python-Dev] Py_SETREF again

[Serhiy Storchaka]

On 12.02.16 15:43, Georg Brandl wrote:

On 02/12/2016 10:45 AM, Serhiy Storchaka wrote:

Sorry to bringing this up again. I was hoping we were done with that.

When discussing the name of the Py_SETREF macro I was supposed to add a
pair of macros: for Py_DECREF and Py_XDECREF. But I got a lot of
opinions to be limited to only one macro.

There was no (besides my) clearly expressed vote for two macros.


I would have voted in favor.

Spelling the SETREF out, as Nick proposes, kind of defies the purpose of
the macro: it's not strictly a convenience macro, it helps prevent
refcounting bugs.


As a result I have replaced both Py_DECREF and Py_XDECREF with the macro
that always uses Py_XDECREF.


Can you roughly say which fraction of replacements changed DECREF to an
implicit XDECREF?


Changesets c4e8751ce637, bc7c56a225de, 539ba7267701, b02d256b8827, 
1118dfcbcc35. Rough estimation:


Py_DECREF - 62
Py_XDECREF - 57
Py_CLEAR - 46

Total statistic of using macros in current code:

Py_SETREF174   2.5%
Py_CLEAR 781  11%
Py_XDECREF  1443  20.5%
Py_DECREF   4631  66%


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

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

[Victor Stinner]

Hi,

2016-02-12 14:31 GMT+01:00 M.-A. Lemburg :
> Sorry, your email must gotten lost in my inbox.

no problemo


> Yes, but those are part of the stdlib. You'd need to check
> a few C extensions which are not tested as part of the stdlib,
> e.g. numpy, scipy, lxml, pillow, etc. (esp. ones which implement custom
> types in C since these will often need the memory management
> APIs).
>
> It may also be a good idea to check wrapper generators such
> as cython, swig, cffi, etc.

Ok, I will try my patch on some of them. Thanks for the pointers.


> I suppose such a flag would create a noticeable runtime
> performance hit, since the compiler would no longer be
> able to inline the PyMem_*() APIs if you redirect those
> APIs to other sets at runtime.

Hum, I think that you missed the PEP 445. The overhead of this PEP was
discussed and considered as negligible enough to implement the PEP:
https://www.python.org/dev/peps/pep-0445/#performances

Using the PEP 445, there is no overhead to enable debug hooks at
runtime (except of the overhead of the debug checks themself ;-)).

PyMem_Malloc now calls a pointer:
https://hg.python.org/cpython/file/37bacf3fa1f5/Objects/obmalloc.c#l319

Same for PyObject_Malloc:
https://hg.python.org/cpython/file/37bacf3fa1f5/Objects/obmalloc.c#l380


> I also don't see much point in carrying around such
> baggage in production builds of Python, since you'd most
> likely only want to use the tools to debug C extensions during
> their development.

I propose adding an environment variable because it's rare that a
debug build is installed on system. Usually, using a debug build
requires to recompile all C extensions which is not really...
convenient...

With such env var, it would be trivial to check quickly if the Python
memory allocators are used correctly.


> Runtime performance, difference in memory consumption (arenas
> cannot be freed if there are still small chunks allocated),
> memory locality. I'm no expert in this, so can't really
> comment much.

"arenas cannot be freed if there are still small chunks allocated"
yeah, this is called memory fragmentation.

There is a big difference between libc malloc() and pymalloc for small
allocations: pymalloc is able to free an arena using munmap() which
releases immediatly the memory to the system, whereas most
implementation of malloc() use a single contigious memory block which
is only shrinked when all memory "at the top" is free. So it's the
same fragmentation issue that you described, except that it uses a
single arena which has an arbitrary size (between 1 MB and 10 GB,
there is no limit), whereas pymalloc uses small arenas of 256 KB.

In short, I expect less fragmentation with pymalloc.

"memory locality": I have no idea on that. I guess that it can be seen
on benchmarks. pymalloc is designed for objects with short lifetime.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [ANN] MicroPython 1.6

[Paul Sokolovsky]

Hello,

MicroPython is a lean and efficient Python implementation for
microcontrollers, embedded, and mobile systems (which also runs just as
fine on desktops, servers, and clouds).

https://github.com/micropython/micropython
https://github.com/micropython/micropython/releases/tag/v1.6

There're following major changes since 1.5:

1. LwIP module support for embedded TCP/IP networking.
2. IPv6 support in the Unix port.
3. Beta support for persistent bytecode (similar to CPython's .pyc)
4. 64-bit NaN boxing (improved floating-point performance if enabled).
5. Support for new official PyBoards PYBv1.1 and PYBLITEv1.0.
6. Long int constant folding during bytecode compilation (glad that
CPython will catch up in that area thanks to FAT Python project).
7. There's a ongoing crowdfunding campaign to fund complete and
well-maintained MicroPython port to ubiquitous ESP8266 WiFi SoC, and
improve networking and IoT support in MicroPython in general:

https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
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

[Python tracker]

ACTIVITY SUMMARY (2016-02-05 - 2016-02-12)
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:
  open5417 ( +4)
  closed 32691 (+50)
  total  38108 (+54)

Open issues with patches: 2368 


Issues opened (39)
==

#22107: tempfile module misinterprets access denied error on Windows
http://bugs.python.org/issue22107  reopened by serhiy.storchaka

#25911: Regression: os.walk now using os.scandir() breaks bytes filena
http://bugs.python.org/issue25911  reopened by serhiy.storchaka

#26299: wsgiref.util FileWrapper raises ValueError: I/O operation on c
http://bugs.python.org/issue26299  opened by samwyse

#26300: "unpacked" bytecode
http://bugs.python.org/issue26300  opened by abarnert

#26302: cookies module allows commas in keys
http://bugs.python.org/issue26302  opened by jason.coombs

#26303: Shared execution context between doctests in a module
http://bugs.python.org/issue26303  opened by kernc

#26305: Make Argument Clinic to generate PEP 7 conforming code
http://bugs.python.org/issue26305  opened by serhiy.storchaka

#26306: Can't create abstract tuple
http://bugs.python.org/issue26306  opened by Jack Hargreaves

#26307: no PGO for built-in modules with `make profile-opt`
http://bugs.python.org/issue26307  opened by tzot

#26308: Solaris 10 build issues
http://bugs.python.org/issue26308  opened by gms

#26309: socketserver.BaseServer._handle_request_noblock() don't shutdw
http://bugs.python.org/issue26309  opened by palaviv

#26313: ssl.py _load_windows_store_certs fails if windows cert store i
http://bugs.python.org/issue26313  opened by Jonathan Kamens

#26314: interned strings are stored in a dict, a set would use less me
http://bugs.python.org/issue26314  opened by gregory.p.smith

#26316: Probable typo in Arg Clinic’s linear_format()
http://bugs.python.org/issue26316  opened by martin.panter

#26317: Build Problem with GCC + Macintosh OS X 10.11 El Capitain
http://bugs.python.org/issue26317  opened by Robert P Fischer

#26318: `io.open(fd, ...).name` returns numeric fd instead of None
http://bugs.python.org/issue26318  opened by mmarkk

#26319: Check recData size before unpack in zipfile
http://bugs.python.org/issue26319  opened by j w

#26322: Missing docs for typing.Set
http://bugs.python.org/issue26322  opened by gvanrossum

#26323: Add a assert_called() method for mock objects
http://bugs.python.org/issue26323  opened by Amit.Saha

#26326: Named entity "vertical line" missed in 2.7 htmlentitydefs.py
http://bugs.python.org/issue26326  opened by andreas.roehler

#26327: File > Save in IDLE shell window not working
http://bugs.python.org/issue26327  opened by xflr6

#26328: shutil._copyxattr() function shouldn't fail if setting securit
http://bugs.python.org/issue26328  opened by bigon

#26329: os.path.normpath("//") returns //
http://bugs.python.org/issue26329  opened by Fred Rolland

#26330: shutil.disk_usage() on Windows can't properly handle unicode
http://bugs.python.org/issue26330  opened by giampaolo.rodola

#26331: Tokenizer: allow underscores for grouping in numeric literals
http://bugs.python.org/issue26331  opened by georg.brandl

#26332: OSError: exception: access violation writing <...> (Windows 10
http://bugs.python.org/issue26332  opened by jk

#26333: Multiprocessing imap hangs when generator input errors
http://bugs.python.org/issue26333  opened by Aaron Halfaker

#26334: bytes.translate() doesn't take keyword arguments; docs suggest
http://bugs.python.org/issue26334  opened by Nicholas Chammas

#26335: Make mmap.write return the number of bytes written like other 
http://bugs.python.org/issue26335  opened by jstasiak

#26336: Expose regex bytecode as attribute of compiled pattern object
http://bugs.python.org/issue26336  opened by Jonathan Goble

#26337: Bypass imghdr module determines the type of image
http://bugs.python.org/issue26337  opened by Ramin Farajpour Cami

#26338: remove duplicate bind addresses in create_server
http://bugs.python.org/issue26338  opened by sebastien.bourdeauducq

#26340: modal dialog with transient method; parent window fails to ico
http://bugs.python.org/issue26340  opened by vs

#26342: Faster bit ops for single-digit positive longs
http://bugs.python.org/issue26342  opened by yselivanov

#26346: PySequenceMethods documentation missing sq_slice and sq_ass_sl
http://bugs.python.org/issue26346  opened by atuining

#26347: BoundArguments.apply_defaults doesn't handle empty arguments
http://bugs.python.org/issue26347  opened by Frederick Wagner

#26348: activate.fish sets VENV prompt incorrectly
http://bugs.python.org/issue26348  opened by Dan McCombs

#26349: Ship python35.lib with the embedded distribution, please
http://bugs.python.org/issue26349  opened by Thomas Führinger

#26350: Windoes: signal doc should state certains signals can't be reg
http://bugs.python.org/issue26350  opened by giampaolo.rodola

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Chris Barker]

On Fri, Feb 12, 2016 at 1:00 AM, Paul Moore  wrote:

>
> I have no opinion on anything other than that whatever syntax is
> implemented as long as it allows single underscores between digits,
> such as
>
> 1_000_000
>
> Everything else is irrelevant to me, and if I read code that uses
> anything else, I'd judge it based on readability and style, and
> wouldn't care about arguments that "it's allowed by the grammar".


I totally agree -- and it's clear that other cultures group digits
differently, so we should allow that, but while I'll live with it either
way, I'd rather have it be as restrictive as possible rather than as
unrestricted as possible. As in:

no double underscores
no underscore right before or after a period
no underscore at the beginning or end.


As Paul said, as long as I can do the above, I'll be fine, but I think
everyone's source code will be a lot cleaner in the long run if you don't
have the option of doing who knows what weird arrangement

As for the SS# example -- it seems a bad idea to me to store a SS# number
as an integer anyway -- so all the weird IDs etc. formats aren't really
relevant...

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[MRAB]

On 2016-02-12 20:06, Chris Barker wrote:

On Fri, Feb 12, 2016 at 1:00 AM, Paul Moore mailto:p.f.mo...@gmail.com>> wrote:


I have no opinion on anything other than that whatever syntax is
implemented as long as it allows single underscores between digits,
such as

1_000_000

Everything else is irrelevant to me, and if I read code that uses
anything else, I'd judge it based on readability and style, and
wouldn't care about arguments that "it's allowed by the grammar".


I totally agree -- and it's clear that other cultures group digits
differently, so we should allow that, but while I'll live with it either
way, I'd rather have it be as restrictive as possible rather than as
unrestricted as possible. As in:

no double underscores
no underscore right before or after a period
no underscore at the beginning or end.


As Paul said, as long as I can do the above, I'll be fine, but I think
everyone's source code will be a lot cleaner in the long run if you
don't have the option of doing who knows what weird arrangement

As for the SS# example -- it seems a bad idea to me to store a SS#
number as an integer anyway -- so all the weird IDs etc. formats aren't
really relevant...

That also applies to telephone numbers, account numbers, etc. They 
aren't really numbers (you wouldn't do arithmetic on them) and might 
have leading zeros.


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

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Glenn Linderman]

On 2/12/2016 12:06 PM, Chris Barker wrote:
On Fri, Feb 12, 2016 at 1:00 AM, Paul Moore > wrote:



I have no opinion on anything other than that whatever syntax is
implemented as long as it allows single underscores between digits,
such as

1_000_000

Everything else is irrelevant to me, and if I read code that uses
anything else, I'd judge it based on readability and style, and
wouldn't care about arguments that "it's allowed by the grammar".


I totally agree -- and it's clear that other cultures group digits 
differently, so we should allow that, but while I'll live with it 
either way, I'd rather have it be as restrictive as possible rather 
than as unrestricted as possible. As in:


no double underscores


Useful for really long binary constants... one _ for nybble or field 
divisions, two __ for byte divisions.


Of course, really long binary constants might be a bad idea.


no underscore right before or after a period
no underscore at the beginning or end.


You get your wish for the beginning... it would be ambiguous with 
identifiers. And your style guide can include whatever restrictions you 
like, for your code.





As Paul said, as long as I can do the above, I'll be fine, but I think 
everyone's source code will be a lot cleaner in the long run if you 
don't have the option of doing who knows what weird arrangement


As for the SS# example -- it seems a bad idea to me to store a SS# 
number as an integer anyway -- so all the weird IDs etc. formats 
aren't really relevant...


SS#... why not integer?  Phone#... why not integer? There's a lot of 
nice digit-division conventions for phone#s in different parts of the world.


The only ambiguity is if such numbers have leading zeros, you have to 
"know" (or record) how many total digits are expected.


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

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Andrew Barnert via Python-Dev]

On Feb 12, 2016, at 12:58, Glenn Linderman  wrote:
> 
>> On 2/12/2016 12:06 PM, Chris Barker wrote:
>> As for the SS# example -- it seems a bad idea to me to store a SS# number as 
>> an integer anyway -- so all the weird IDs etc. formats aren't really 
>> relevant...
> 
> SS#... why not integer?  Phone#... why not integer? There's a lot of nice 
> digit-division conventions for phone#s in different parts of the world.

I'm the one who brought up the SSN example--and, as I said at the time, I 
almost certainly wouldn't have done that in Python. I was maintaining tests for 
a service that stored SSNs as integers (which I think is a mistake, but I 
couldn't change it), a automatically-generated strongly-typed interface to that 
service (which is good), and no easy way to wrap or hook that interface (which 
is bad). In Python, it's hard to imagine how I'd end up with a situation where 
I couldn't wrap or hook the interface and treat SSNs as strings in my test 
code. (In fact, for complicated tests, I did exactly that in Python to make 
sure they were correct, then ported them over to integrate with the test 
suite...)

And anyway, the only point was that I've actually used a grouping that isn't 
"every 3 digits" and it didn't end the world. I think everyone agrees that some 
such groupings will come up--even if not every specific examples is good, there 
are some that are. Even the people who want something more conservative than 
the PEP doesn't seem to be taking that position--they may not want double 
underscores, or "123_456_j", but they're fine with "if yuan > _:".

So, either we try to anticipate every possible way people might want to group 
numbers and decide which ones are good or bad, or we just let the style guide 
say "meaningful group of digits" and let each developer decide what counts as 
"meaningful" for their application. Does anyone really want to argue for the 
former? 

If not, why not just settle that and go back to bikeshedding the cases that 
*are* contended, like "123_456_j"? (I'm happy either way, as long as the 
grammar rule is dead simple and the PEP 8 rule is pretty simple, but I know 
others have strong, and conflicting, opinions on that.)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Paul Moore]

On 12 February 2016 at 20:06, Chris Barker  wrote:
> As Paul said, as long as I can do the above, I'll be fine, but I think
> everyone's source code will be a lot cleaner in the long run if you don't
> have the option of doing who knows what weird arrangement

Just to be clear, I'm personally in favour of less restrictions rather
than more (as a general principle) - consenting adults and all that.
But I'm also in favour of less debate rather than more on this issue,
so I'll shut up at this point :-)

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com