Re: [Python-Dev] Removing PendingDeprecationWarning

[Inada Naoki]

I created the PR to deprecate PendingDeprecationWarning only in document.
https://github.com/python/cpython/pull/12505

On Sat, Mar 23, 2019 at 10:18 AM Inada Naoki  wrote:
>
> On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon  wrote:
> >
> >>
> >> There might be some small troubles.  But it was small enough for
> >> Python minor versions, I think.
> >
> >
> >  I don't think it's worth the cost to users. We can just choose to stop 
> > using it in the stdlib and not use PendingDeprecationWarning. And if people 
> > want to force others to define their own PendingDeprecationWarning by 
> > deprecating that's fine, but the aliasing where it could cause unintended 
> > exception swallowing for something related to breaking changes seems 
> > unnecessarily risky to me simply because we don't want to ask users to 
> > update their code in a backwards-compatible fashion.
>
> I still can't believe there are real world usage of PendingDeprecationWarning
> other than warnings.warn() and assertRaises().
>
> But I'm OK to not removing actual class.
>
> Stop using it in stdlib reduces maintenance cost like this:
> https://github.com/python/cpython/pull/12494/files
>
> And deprecation in document reduces learning cost.
> People can skip reading and understanding document of 
> PendingDeprecatedWarning.
>
> Keeping PendingDeprecationWarning class for several years is very
> low cost compared to these cost.
>
> Regards,
> --
> Inada Naoki  



-- 
Inada Naoki  
___
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] Removing PendingDeprecationWarning

[Inada Naoki]

On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon  wrote:
>
>>
>> There might be some small troubles.  But it was small enough for
>> Python minor versions, I think.
>
>
>  I don't think it's worth the cost to users. We can just choose to stop using 
> it in the stdlib and not use PendingDeprecationWarning. And if people want to 
> force others to define their own PendingDeprecationWarning by deprecating 
> that's fine, but the aliasing where it could cause unintended exception 
> swallowing for something related to breaking changes seems unnecessarily 
> risky to me simply because we don't want to ask users to update their code in 
> a backwards-compatible fashion.

I still can't believe there are real world usage of PendingDeprecationWarning
other than warnings.warn() and assertRaises().

But I'm OK to not removing actual class.

Stop using it in stdlib reduces maintenance cost like this:
https://github.com/python/cpython/pull/12494/files

And deprecation in document reduces learning cost.
People can skip reading and understanding document of PendingDeprecatedWarning.

Keeping PendingDeprecationWarning class for several years is very
low cost compared to these cost.

Regards,
-- 
Inada Naoki  
___
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] Invitation to the PyCon typing summit (Thu, May 2nd, 1-5pm, at PyCon in Cleveland)

[Guido van Rossum]

The typing summit is primarily a place for developers of type checkers to
collaborate, but we are also inviting (potential) users of type checkers.
For example, there are plans to extend the standard Python type system with
features intended to support numpy, Pandas, tensorflow and similar
libraries, and we will discuss these at the summit. Therefore developers
and power-users of such frameworks are especially welcome at the summit.

With Ewa's and Dropbox's help I've arranged a room at PyCon.


*When: Thursday May 2nd, 1-5 pm (i.e. the day between the Language Summit
and the conference proper)*
*Where: Room 6 at PyCon in Cleveland*

If you're planning to attend, please fill out this form:

https://goo.gl/forms/rG9dVTBbgyBgDK8H2

*If you already emailed me about attending, please still fill out the form!*

(Also if you already registered in response to my invitation on typing-sig,
I've got your registration info.)


-- 
--Guido van Rossum (python.org/~guido)
___
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] Removing PendingDeprecationWarning

[Steve Dower]

On 22Mar2019 1101, Brett Cannon wrote:
On Fri, Mar 22, 2019 at 10:37 AM Inada Naoki > wrote:

There might be some small troubles.  But it was small enough for
Python minor versions, I think.


  I don't think it's worth the cost to users. We can just choose to stop 
using it in the stdlib and not use PendingDeprecationWarning. And if 
people want to force others to define their own 
PendingDeprecationWarning by deprecating that's fine, but the aliasing 
where it could cause unintended exception swallowing for something 
related to breaking changes seems unnecessarily risky to me simply 
because we don't want to ask users to update their code in a 
backwards-compatible fashion.


What does it mean to put DeprecationWarning on PendingDeprecationWarning 
and then alias PendingDeprecationWarning to DeprecationWarning?


"If the implementation is hard to explain, it's a bad idea." :)

(FWIW, agree with Brett. We can simply stop using it ourselves without 
breaking anyone. Of all the things in the stdlib that are hard to 
maintain, this is nowhere near the top of the list.)


Cheers,
Steve
___
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 (2019-03-15 - 2019-03-22)
Python tracker at https://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:
  open7051 ( +3)
  closed 41100 (+91)
  total  48151 (+94)

Open issues with patches: 2817 


Issues opened (55)
==

#35121: Cookie domain check returns incorrect results
https://bugs.python.org/issue35121  reopened by xtreak

#36309: Remove tempfile.mktemp()
https://bugs.python.org/issue36309  opened by John Hagen

#36310: pygettext3.7 Does Not Recognize gettext Calls Within fstrings
https://bugs.python.org/issue36310  opened by Allie Fitter

#36311: Flaw in Windows code page decoder for large input
https://bugs.python.org/issue36311  opened by serhiy.storchaka

#36313: error: [Errno 13] Permission denied: '/usr/local/lib/python3.7
https://bugs.python.org/issue36313  opened by bunhin

#36315: Unable to install Python 3.7.2
https://bugs.python.org/issue36315  opened by ecesu...@gmail.com

#36318: Adding support for setting the "disabled" attribute of loggers
https://bugs.python.org/issue36318  opened by maggyero

#36319: Erro 0xC374 on windows 10
https://bugs.python.org/issue36319  opened by heckad

#36322: Argument typo in dbm.ndbm.open
https://bugs.python.org/issue36322  opened by rougeth

#36323: IDLE: always display full grep path
https://bugs.python.org/issue36323  opened by terry.reedy

#36326: Build-out help() to read __slots__ with an optional data dicti
https://bugs.python.org/issue36326  opened by rhettinger

#36329: use the right python "make -C Doc/ serve"
https://bugs.python.org/issue36329  opened by matrixise

#36330: Warning about a potential dead code in timemodule and Clang
https://bugs.python.org/issue36330  opened by matrixise

#36335: Factor out / add bdb.Bdb.is_skipped_frame
https://bugs.python.org/issue36335  opened by blueyed

#36338: urlparse of urllib returns wrong hostname
https://bugs.python.org/issue36338  opened by Xianbo Wang

#36339: test_ttk_guionly: test_traversal() fails randomly on AMD64 Win
https://bugs.python.org/issue36339  opened by vstinner

#36340: 3.7.3rc1 Install Certificates fails on macOS
https://bugs.python.org/issue36340  opened by Dima.Tisnek

#36341: bind() on AF_UNIX socket may fail in tests run as non-root
https://bugs.python.org/issue36341  opened by xdegaye

#36342: test_venv failure when executed by test_multiprocessing and th
https://bugs.python.org/issue36342  opened by xdegaye

#36345: Deprecate Tools/scripts/serve.py in favour of python -m http.s
https://bugs.python.org/issue36345  opened by matrixise

#36346: Prepare for removing the legacy Unicode C API
https://bugs.python.org/issue36346  opened by serhiy.storchaka

#36347: Renaming the constants for the .flags of PyMemberDef
https://bugs.python.org/issue36347  opened by matrixise

#36348: test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails rando
https://bugs.python.org/issue36348  opened by vstinner

#36350: inspect.Signature.parameters and inspect.BoundArguments.argume
https://bugs.python.org/issue36350  opened by remi.lapeyre

#36351: the ipv6type variable in configure.ac may be set incorrectly w
https://bugs.python.org/issue36351  opened by xdegaye

#36353: rpath incorrectly handled on OSX by build_ext
https://bugs.python.org/issue36353  opened by Toon Verstraelen

#36354: Use CreateProcessW for Python 2.7 on Windows.
https://bugs.python.org/issue36354  opened by Ray Donnelly

#36355: Remove documentation and internal use of the *RESTRICTED const
https://bugs.python.org/issue36355  opened by josh.r

#36356: Failure to build with address sanitizer
https://bugs.python.org/issue36356  opened by btharper

#36359: contextvars documentation unclear on thread-locality
https://bugs.python.org/issue36359  opened by Hameer Abbasi2

#36361: generate correct pyconfig.h when cross-compiling
https://bugs.python.org/issue36361  opened by xdegaye

#36364: errors in multiprocessing.shared_memory examples
https://bugs.python.org/issue36364  opened by pierreglaser

#36366: Patcher stop method should be idempotent
https://bugs.python.org/issue36366  opened by sfreilich

#36368: server process of shared_memory shuts down if KeyboardInterrup
https://bugs.python.org/issue36368  opened by pierreglaser

#36369: test_weakref super slow on RPi Zero
https://bugs.python.org/issue36369  opened by DNSGeek

#36370: Check for PyErr_Occurred() after PyImport_GetModule().
https://bugs.python.org/issue36370  opened by asmeurer

#36372: Flawed handling of URL redirect
https://bugs.python.org/issue36372  opened by bugburger

#36373: asyncio.gather: no docs for deprecated loop parameter
https://bugs.python.org/issue36373  opened by dtrauma

#36375: PEP 499 implementation: "python -m foo" binds the main module 
https://bugs.python.org/issue36375  opened by cameron

#36377: Python 'datastructures.html' docs page needs improvement becau
https://bugs.python.org/issue36377  opened by 

Re: [Python-Dev] Removing PendingDeprecationWarning

[Inada Naoki]

On Sat, Mar 23, 2019 at 2:26 AM Brett Cannon  wrote:
>
>
> We can't do that as it will break code. Think of code which is having 
> warnings raise exceptions and that are purposefully catching 
> PendingDeprecationWarning but not DeprecationWarning; this change would break 
> that. These classes are part of the public API of the warnings module and so 
> we shouldn't change semantics like that for people who have a specific use 
> for those two different classes regardless of how the stdlib may choose to 
> use them.
>

Didn't we already do it?  socket.error was independent error class.
It became alias of OSError from Python 3.3.

There might be some small troubles.  But it was small enough for
Python minor versions, I think.


-- 
Inada Naoki  
___
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] Removing PendingDeprecationWarning

[Brett Cannon]

On Fri, Mar 22, 2019 at 12:41 AM Victor Stinner  wrote:

> Hi,
>
> I agree to make PendingDeprecationWarning an alias to
> DeprecationWarning. I never liked "PendingDeprecationWarning" name,
> it's way too long to type :-D
>
> Le ven. 22 mars 2019 à 03:45, Inada Naoki  a
> écrit :
> > I want to stop using PendingDeprecationWarning for new deprecation.
>
> I'm fine with that.
>
> > More aggressively, I want to remove PendingDeprecationWarning class,
> > and `PendingDeprecationWarning = DeprecationWarning` for backward
> > compatibility.
>
> I'm not sure that I understand well. Do you want to remove the
> PendingDeprecationWarning builtin symbol, or just make it an alias to
> DeprecationWarning.
>
> I'm fine with "PendingDeprecationWarning = DeprecationWarning".
>

We can't do that as it will break code. Think of code which is having
warnings raise exceptions and that are purposefully catching
PendingDeprecationWarning but not DeprecationWarning; this change would
break that. These classes are part of the public API of the warnings module
and so we shouldn't change semantics like that for people who have a
specific use for those two different classes regardless of how the stdlib
may choose to use them.


>
> IMHO your email title is misleading. You don't want to *remove*
> PendingDeprecationWarning, you only want to make it an alias to
> DeprecationWarning, right? In term of backward compatibility, it's
> very different :-)
>

If you want to remove PendingDeprecationWarning that's a discussion we can
obviously have (which I disagree with as shown in the discuss.python.org
discussion), but I think aliasing is a non-starter.
___
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] Replacement for array.array('u')?

[Steve Dower]

On 22Mar2019 0433, Antoine Pitrou wrote:

The question is: why would you use a array.array() with a Windows C API?


I started replying to this with a whole lot of examples, and eventually 
convinced myself that you wouldn't (or shouldn't).


That said, I see value in having a type for array/struct/memoryview that 
"is the same size as wchar_t", since that will avoid people having to 
guess (the docs for array in particular are deliberately vague about the 
actual size of the various types).


This is not the same as "UCS-4" - that's a very Linux-centric point of 
view. Decoupling it from Py_UNICODE is fine though, since that type will 
have no meaning eventually. But the PyUnicode_*WideChar APIs are not 
going away, which means that wchar_t still exists and has to have a 
known size at compile time.


Cheers,
Steve
___
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] Removing PendingDeprecationWarning

[Victor Stinner]

Le ven. 22 mars 2019 à 13:05, Serhiy Storchaka  a écrit :
> > The main problem is complexity.  In other words, learning cost.
>
> Do you have evidences that many people have troubles with learning
> PendingDeprecationWarning?

I have no idea when I should use PendingDeprecationWarning rather than
DeprecationWarning. For example, let's say that we deprecate a feature
in Python N with an open question of remove it from Python N+1 or N+2.
Should I started with PendingDeprecationWarning?

The following discussion mentioned that many deprecated features are
not removed just because everybody forgot to remove it:
https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038

And I consider that it's perfectly fine to not have a strict plan to
remove a feature as part of a deprecation. The usage of a deprecated
feature can evolve. There are a few exceptions of deprecated features
which were only modified to remove the deprecation, rather than
removing the feature, because we decided that the fetaure must stay.
Python language is living, its usage is changing frequently.

About showing warnings: I never ever used a specific filter to only
hide PendingDeprecationWarning but show DeprecationWarning. When I
want to fix warnings, I want to fix all of them, pending or not. I
would like to prepare a project for all future Python versions, not
only fix DeprecationWarning.

"python3 -X dev", "python3 -Wd" and python3 compiled in debug modes
all show DeprecationWarning *and* PendingDeprecationWarning. The
granularity no longer matters.

It was useful to have PendingDeprecationWarning when it was hidden by
default, whereas DeprecationWarning warnings were displayed by
default. But now both are hidden by default.

Well, maybe read the whole previous discussion for the full rationale:
https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038



> Perhaps the better solution of this is to improve the documentation.
>
> PendingDeprecationWarning means that you still can use the deprecated
> feature.

Honestly, I'm not really excited by using a feature that is tagged to
be deprecated in the future... IMHO the difference between
PendingDeprecationWarning and DeprecationWarning is too subtle to be
useful in practice.


> PendingDeprecationWarning just give us time to add an alternate way if
> it is not available yet, and give Python programmers time to adapt their
> code.

Do you have some examples?

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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] Replacement for array.array('u')?

[Antoine Pitrou]

On Fri, 22 Mar 2019 16:11:45 +0200
Serhiy Storchaka  wrote:
> 22.03.19 13:33, Antoine Pitrou пише:
> > On Fri, 22 Mar 2019 13:27:08 +0200
> > Serhiy Storchaka  wrote:  
> >> Making it always 32 bits would be compatibility breaking change.
> >> Currently array('u') represents the wchar_t string, and many API on
> >> Windows require it.  
> > 
> > The question is: why would you use a array.array() with a Windows C API?  
> 
> I do not. But maybe it is used. And changing the width of the 'u' code 
> would break such use case.

Right.  But changing the width is not what I had in mind.  Just keep it
identical until we finally decide to remove it.

Regards

Antoine.


___
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] Replacement for array.array('u')?

[Serhiy Storchaka]

22.03.19 13:33, Antoine Pitrou пише:

On Fri, 22 Mar 2019 13:27:08 +0200
Serhiy Storchaka  wrote:

Making it always 32 bits would be compatibility breaking change.
Currently array('u') represents the wchar_t string, and many API on
Windows require it.


The question is: why would you use a array.array() with a Windows C API?


I do not. But maybe it is used. And changing the width of the 'u' code 
would break such use case.


___
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] Replacement for array.array('u')?

[Antoine Pitrou]

On Fri, 22 Mar 2019 12:51:49 +0100
Stefan Behnel  wrote:
> Antoine Pitrou schrieb am 22.03.19 um 11:39:
> > On Fri, 22 Mar 2019 20:31:33 +1300 Greg Ewing wrote:  
> >> A poster on comp.lang.python is asking about array.array('u').
> >> He wants an efficient mutable collection of unicode characters
> >> that can be initialised from a string.  
> > 
> > TBH, I think anyone trying to use array.array should be directed to
> > Numpy these days.  The only reason for array.array being here is that
> > it predates Numpy.  Otherwise we'd never have added it.  
> 
> Well, maybe it wouldn't get *added* these days anymore, with pip+PyPI
> nicely in place. But being there already, it makes for a nice and efficient
> "batteries included" list replacement for simple data that would otherwise
> waste a lot of object memory.

It's not really "batteries included".  array.array() supports almost no
useful operation. It's a bare-bones container for which you have to
implement every useful feature by yourself.

(yes, you can use generic mutable sequence algorithms such
as heapq or random.shuffle; how often do you need to heapify or shuffle
an array of unicode codepoints?)

Also, when using a unicode array, there's no substantial win of memory
compared to a single str object.  You may be losing some actually,
because of the flexible str representation.

Regards

Antoine.


___
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] Removing PendingDeprecationWarning

[Serhiy Storchaka]

22.03.19 13:23, Inada Naoki пише:

On Fri, Mar 22, 2019 at 7:36 PM Serhiy Storchaka  wrote:

What is wrong with PendingDeprecationWarning? What problem do you want
to solve at the cost of removing this feature?



The main problem is complexity.  In other words, learning cost.


Do you have evidences that many people have troubles with learning 
PendingDeprecationWarning?



All Python library developer would like to know how to deprecate something.

They will understand "deprecated" means "will be removed in the future
version" easily.

Then, "will be deprecated" [1] is easy to understand?  "will be (will
be removed)"
is very curious.  To understand what PendingDeprecationWarning is for, they
need to learn history which is not documented in clearly.

[1]: https://docs.python.org/3/library/exceptions.html#PendingDeprecationWarning


Perhaps the better solution of this is to improve the documentation.

PendingDeprecationWarning means that you still can use the deprecated 
feature.


When we deprecate some feature, we should provide an alternate way to 
solve the same problem. And it is better if that way is available in few 
previous Python versions. So the developer which need to support several 
Python versions could just switch to a modern way. This is how we do, or 
at least must to do, to be polite with Python programmers.


PendingDeprecationWarning just give us time to add an alternate way if 
it is not available yet, and give Python programmers time to adapt their 
code.



If we deprecate PendingDeprecationWarning, people don't have to understand
what it is for.



Now, when DeprecationWarning is displayed by default in the interactive
session, in __main__ and in development runtime mode (and this list can
be extended), PendingDeprecationWarning is useful again. Even if the
interpreter itself would not use it, it is used in third-party projects.



This benefits seems too small compared to the learning cost.


I do not think so.

___
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] Replacement for array.array('u')?

[Stefan Behnel]

Antoine Pitrou schrieb am 22.03.19 um 11:39:
> On Fri, 22 Mar 2019 20:31:33 +1300 Greg Ewing wrote:
>> A poster on comp.lang.python is asking about array.array('u').
>> He wants an efficient mutable collection of unicode characters
>> that can be initialised from a string.
> 
> TBH, I think anyone trying to use array.array should be directed to
> Numpy these days.  The only reason for array.array being here is that
> it predates Numpy.  Otherwise we'd never have added it.

Well, maybe it wouldn't get *added* these days anymore, with pip+PyPI
nicely in place. But being there already, it makes for a nice and efficient
"batteries included" list replacement for simple data that would otherwise
waste a lot of object memory.

Stefan

___
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] Removing PendingDeprecationWarning

[Inada Naoki]

On Fri, Mar 22, 2019 at 8:49 PM Serhiy Storchaka  wrote:
>
> > And I can easily ask the converse question: what problem do you want to
> > solve by including that feature?
>
> It allowed to mark a feature deprecated for developers without harming
> the end users.
>

Both of DeprecationWarning and PendingDeprecationWarning are not for end users.
Only FutureWarning is for end users now.

-- 
Inada Naoki  
___
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] Removing PendingDeprecationWarning

[Serhiy Storchaka]

22.03.19 12:51, Jeroen Demeyer пише:

On 2019-03-22 11:33, Serhiy Storchaka wrote:

What is wrong with PendingDeprecationWarning?


It serves the same purpose as DeprecationWarning: it indicates that a 
feature is planned to be removed in the future. There is no point in 
having two warnings with exactly the same meaning.


But does not flood the end user with warnings, so you can continue to 
use deprecated features for a while. This makes the transition more smooth.



What problem do you want
to solve at the cost of removing this feature?


1. Typically, a PendingDeprecationWarning is meant to be promoted to a 
DeprecationWarning in some future release. It takes a minor effort to do 
that and it may be forgotten. It's just simpler to use 
DeprecationWarning from the start.


What is wrong if it be forgotten?

Simpler does not mean better.

2. Whenever somebody wants to deprecate something, that person has to 
decide between the two. That's just more complicated than it needs to be.


If he want to provide a more smooth transition way, he should start with 
a PendingDeprecationWarning. Otherwise he can use a DeprecationWarning.


And I can easily ask the converse question: what problem do you want to 
solve by including that feature?


It allowed to mark a feature deprecated for developers without harming 
the end users.


___
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] Replacement for array.array('u')?

[Serhiy Storchaka]

22.03.19 09:45, Victor Stinner пише:

Internally, CPython has a _PyUnicodeWriter which is an efficient way
to create a string but appending substrings or characters.
_PyUnicodeWriter changes the internal storage format depending on
characters code points (ascii or latin1: 1 byte/character, BMP: 2 b/c,
full UCS: 4 b/c). I tried once to expose it in Python, but I wasn't
convinced by performances. The overhead of method calls was quite
significant, and I wasn't convinced by "writer += str" performance
neither. Maybe I should try again. PyPy also has such object. It
avoids the "str += str" hack in ceval.c to avoid very poor performance
(_PyUnicodeWriter also uses overallocation which can be controlled
with multiple parameters to reduce the number of realloc).

Another alternative would be have to add a "strarray" type similar to
bytes/bytearray couple.


Another alternative of mutable string buffer and string builder is 
io.StringIO.


___
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] Replacement for array.array('u')?

[Antoine Pitrou]

On Fri, 22 Mar 2019 13:27:08 +0200
Serhiy Storchaka  wrote:

> 22.03.19 09:31, Greg Ewing пише:
> > A poster on comp.lang.python is asking about array.array('u').
> > He wants an efficient mutable collection of unicode characters
> > that can be initialised from a string.
> > 
> > According to the docs, the 'u' code is deprecated and will be
> > removed in 4.0, but no alternative is suggested.
> > 
> > Why is this being deprecated, instead of keeping it and making
> > it always 32 bits? It seems like useful functionality that can't
> > be easily obtained another way.  
> 
> Making it always 32 bits would be compatibility breaking change. 
> Currently array('u') represents the wchar_t string, and many API on 
> Windows require it.

The question is: why would you use a array.array() with a Windows C API?

Regards

Antoine.


___
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] Replacement for array.array('u')?

[Serhiy Storchaka]

22.03.19 09:31, Greg Ewing пише:

A poster on comp.lang.python is asking about array.array('u').
He wants an efficient mutable collection of unicode characters
that can be initialised from a string.

According to the docs, the 'u' code is deprecated and will be
removed in 4.0, but no alternative is suggested.

Why is this being deprecated, instead of keeping it and making
it always 32 bits? It seems like useful functionality that can't
be easily obtained another way.


Making it always 32 bits would be compatibility breaking change. 
Currently array('u') represents the wchar_t string, and many API on 
Windows require it.


But we can add a new code, e.g. 'U', for UCS4.

___
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] Removing PendingDeprecationWarning

[Inada Naoki]

On Fri, Mar 22, 2019 at 7:36 PM Serhiy Storchaka  wrote:
>
> >
> > How do you think?  May I do it in Python 3.8?
>
> What is wrong with PendingDeprecationWarning? What problem do you want
> to solve at the cost of removing this feature?
>

The main problem is complexity.  In other words, learning cost.

All Python library developer would like to know how to deprecate something.

They will understand "deprecated" means "will be removed in the future
version" easily.

Then, "will be deprecated" [1] is easy to understand?  "will be (will
be removed)"
is very curious.  To understand what PendingDeprecationWarning is for, they
need to learn history which is not documented in clearly.

[1]: https://docs.python.org/3/library/exceptions.html#PendingDeprecationWarning

If we deprecate PendingDeprecationWarning, people don't have to understand
what it is for.


> Now, when DeprecationWarning is displayed by default in the interactive
> session, in __main__ and in development runtime mode (and this list can
> be extended), PendingDeprecationWarning is useful again. Even if the
> interpreter itself would not use it, it is used in third-party projects.
>

This benefits seems too small compared to the learning cost.

-- 
Inada Naoki  
___
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] Removing PendingDeprecationWarning

[Jeroen Demeyer]

On 2019-03-22 11:33, Serhiy Storchaka wrote:

What is wrong with PendingDeprecationWarning?


It serves the same purpose as DeprecationWarning: it indicates that a 
feature is planned to be removed in the future. There is no point in 
having two warnings with exactly the same meaning.



What problem do you want
to solve at the cost of removing this feature?


1. Typically, a PendingDeprecationWarning is meant to be promoted to a 
DeprecationWarning in some future release. It takes a minor effort to do 
that and it may be forgotten. It's just simpler to use 
DeprecationWarning from the start.


2. Whenever somebody wants to deprecate something, that person has to 
decide between the two. That's just more complicated than it needs to be.


And I can easily ask the converse question: what problem do you want to 
solve by including that feature?

___
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] Replacement for array.array('u')?

[Inada Naoki]

FYI, I have created issue on bugs.python.org about adding deprecation warning
for array('u').
https://bugs.python.org/issue36299

I created PR to change Py_UNICODE to Py_UCS4, instead of deprecate it.
https://github.com/python/cpython/pull/12497

Then, I found same change had made and reverted in the past.
https://github.com/python/cpython/commit/62bb394729a167a46d950954c4aed5f3ba7b8a69

The issue for the revert is this.
https://bugs.python.org/issue13072

-- 
Inada Naoki  
___
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] Replacement for array.array('u')?

[Antoine Pitrou]

On Fri, 22 Mar 2019 20:31:33 +1300
Greg Ewing  wrote:
> A poster on comp.lang.python is asking about array.array('u').
> He wants an efficient mutable collection of unicode characters
> that can be initialised from a string.

TBH, I think anyone trying to use array.array should be directed to
Numpy these days.  The only reason for array.array being here is that
it predates Numpy.  Otherwise we'd never have added it.

Regards

Antoine.


___
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] Removing PendingDeprecationWarning

[Serhiy Storchaka]

22.03.19 04:41, Inada Naoki пише:

I'm thinking about removing PendingDeprecationWarning.
(previous discussion:
https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038)

It was added "not be printed by default" version of DeprecationWarning.
But DeprecationWarning is not printed by default now.

We use PendingDeprecationWarning for N-2 release, and change it to
DeprecationWarning for N-1 release.  But this workflow seems not worth
enough for now.

I want to stop using PendingDeprecationWarning for new deprecation.

More aggressively, I want to remove PendingDeprecationWarning class,
and `PendingDeprecationWarning = DeprecationWarning` for backward
compatibility.

How do you think?  May I do it in Python 3.8?


What is wrong with PendingDeprecationWarning? What problem do you want 
to solve at the cost of removing this feature?


Now, when DeprecationWarning is displayed by default in the interactive 
session, in __main__ and in development runtime mode (and this list can 
be extended), PendingDeprecationWarning is useful again. Even if the 
interpreter itself would not use it, it is used in third-party projects.


___
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] Removing PendingDeprecationWarning

[Steve Holden]

On Fri, Mar 22, 2019 at 8:43 AM Victor Stinner  wrote:

> Le ven. 22 mars 2019 à 09:16, Inada Naoki  a
> écrit :
> > > > We have `socket.error` for long time.
> > >
> > > And it's perfectly fine, no?
> > >
> >
> > Yes.  Waiting 10+ years to remove aliases is fine.
>
> [...]

>
> Right now, the maintenance cost is close to zero, whereas removing the
> alias would annoy a lot of people who will suddenly no longer be able
> to use their legacy code (written for Python 2 long time ago, but only
> ported to Python 3 recently). Getting a hard AttributeError exception
> is different than getting a silent DeprecationWarning :-)
>

Quite. Why expend the effort on a development that will cause unnecessary
pain?

Generally speaking, end-users will live their lives in blissful ignorance
of [Pending]DeprecationWarning and should be allowed to do so. When a
developer wants to migrate them to more recent versions of Python there's a
chance that warnings will be enabled and examined, but it's by no means
certain.

I suspect the real value of the warnings is so that the dev team can shrug
their shoulders when someone complains a feature has gone missing after ten
years in deprecated status. This is the price of having them normally
silent, which is certainly worth any trouble it causes by refusing to
hassle innocent non-developers with warnings they can do nothing about.
___
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] Replacement for array.array('u')?

[Steven D'Aprano]

On Fri, Mar 22, 2019 at 08:31:33PM +1300, Greg Ewing wrote:
> A poster on comp.lang.python is asking about array.array('u').
> He wants an efficient mutable collection of unicode characters
> that can be initialised from a string.
> 
> According to the docs, the 'u' code is deprecated and will be
> removed in 4.0, but no alternative is suggested.
> 
> Why is this being deprecated, instead of keeping it and making
> it always 32 bits? It seems like useful functionality that can't
> be easily obtained another way.

I can't answer any of those questions, but perhaps the poster can do 
this instead:

py> a = array('L', 'ℍℰâѵÿ Ϻεταł'.encode('utf-32be'))
py> a
array('L', [220266496, 807469056, 3791650816, 1963196416, 4278190080, 
536870912, 4194500608, 3036872704, 3288530944, 2969763840, 1107361792])

Getting the string out again is no harder:

py> bytes(a).decode('utf-32be')
'ℍℰâѵÿ Ϻεταł'

But having said that, it would be nice to have an array code which 
treated the values as single UTF-32 characters:

array('?', ['ℍ', 'ℰ', 'â', 'ѵ', 'ÿ', ' ', 'Ϻ', 'ε', 'τ', 'α', 'ł'])

if for no other reason than it looks nicer than a bunch of 32 bit ints.


-- 
Steven
___
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] Replacement for array.array('u')?

[Inada Naoki]

On Fri, Mar 22, 2019 at 4:38 PM Greg Ewing  wrote:
>
> A poster on comp.lang.python is asking about array.array('u').
> He wants an efficient mutable collection of unicode characters
> that can be initialised from a string.
>
> According to the docs, the 'u' code is deprecated and will be
> removed in 4.0, but no alternative is suggested.
>
> Why is this being deprecated, instead of keeping it and making
> it always 32 bits? It seems like useful functionality that can't
> be easily obtained another way.
>

I think it's because there are not much use cases found
when implementing PEP 393.

If there are use cases enough to keep it in stdlib, I'm OK
about un-deprecate it and make it always 32bit (int32_t).

-- 
Inada Naoki  
___
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] Removing PendingDeprecationWarning

[Victor Stinner]

Le ven. 22 mars 2019 à 09:16, Inada Naoki  a écrit :
> > > We have `socket.error` for long time.
> >
> > And it's perfectly fine, no?
> >
>
> Yes.  Waiting 10+ years to remove aliases is fine.

Sure.

Let me elaborate my point of view on deprecation, since we are
discussing it here (and I know that my opinion is not fully shared by
all core devs, according to the bpo-35283 discussion, or maybe I'm
wrong?) :-)

Methods of threading.Thread changed their names to comply to PEP 8
coding style in Python 3: isAlive() has been renamed to is_alive().
The Threading.isAlive() method still exists in Python 3.8 and I think
that it's ok. Removing it immediately would go against the best
practice of writing a single code base working on Python 2 and
Python3... I would be very annoyed to have to replace a simple
"thread.isAlive()" call with something like
"six.threading_is_alive(thread)" in my code, just because someone
considered that the alias had to go away from the stdlib.

Last December, Serhiy started to talk about removing isAlive(): "It is
not even documented in Python 3, and can be removed in future."
https://bugs.python.org/issue35283#msg330242

Antoine Pitrou suggested that "If it's not already deprecated, I'd say
deprecate it first." And it has been done.

I'm fine with deprecating things, since it doesn't prevent an
application to be used. Use python3 -Wd (or python3 -X dev) to see
these warnings if you want to be pedantic, but honestly, keeping the
alias doesn't hurt anyone. Again, I mostly care about the maintenance
cost: isAlive() is not documented, it's just 8 lines in threading.py
and 2 lines in test_threading.py, and it's no like these lines require
a lot of maintenance.

IMHO the main metric should be to compare to cost to maintain such
alias vs the pain affecting *all* Python users if we remove it.

Right now, the maintenance cost is close to zero, whereas removing the
alias would annoy a lot of people who will suddenly no longer be able
to use their legacy code (written for Python 2 long time ago, but only
ported to Python 3 recently). Getting a hard AttributeError exception
is different than getting a silent DeprecationWarning :-)

--

Wait, I'm not against removing things from Python. Don't tell anyone,
but I *love* removing code, that's my greatest pleasure! IMHO Python
is way too big and is expensive to maintain. But we should carefully
discuss *each* feature removal, and plan properly a slow deprecation
period to make sure that users had enough time to upgrade (and maybe
extend it if needed).

For Threading.isAlive(), IMHO the fact that Python 2 is still alive is
simply a strong blocker issue. Let's discuss that that Python 2 usage
will be closer to 0,1% than 50% :-) (Sorry, I don't think that it's
really useful to discuss if Python 2 usage is more around 10% or 70%,
that's not really the point: I made up "50%" :-))

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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] Removing PendingDeprecationWarning

[Inada Naoki]

On Fri, Mar 22, 2019 at 5:06 PM Victor Stinner  wrote:
>
> Le ven. 22 mars 2019 à 08:54, Inada Naoki  a écrit :
> > Yes.  It will be removed at some point, but not in near future.
> >
> > But when when backward compatibility can be kept by alias,
> > we can be very lazy about removing it.
>
> Honestly, I don't see the point of removing PendingDeprecationWarning
> anytime soon. Practicality beats purity.

I totally agree.

> Removing PendingDeprecationWarning doesn't bring any value to anyone.
> "PendingDeprecationWarning = DeprecationWarning" costs nothing in term
> of maintenance.
>
> If you care, I would suggest to invest time in static analyzers like
> pycodestyle, pylint, pyflakes, etc. Emit a warning with a low
> priority, and let users make their own choices.

Agree too.

>
> > We have `socket.error` for long time.
>
> And it's perfectly fine, no?
>

Yes.  Waiting 10+ years to remove aliases is fine.


-- 
Inada Naoki  
___
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] Removing PendingDeprecationWarning

[Victor Stinner]

Le ven. 22 mars 2019 à 08:54, Inada Naoki  a écrit :
> Yes.  It will be removed at some point, but not in near future.
>
> But when when backward compatibility can be kept by alias,
> we can be very lazy about removing it.

Honestly, I don't see the point of removing PendingDeprecationWarning
anytime soon. Practicality beats purity. Python is no longer about the
purity of the language (we tried in Python 3.0, not sure that I want
to want to do that again ;-)), but making it convenient to use for
most people.

Removing PendingDeprecationWarning doesn't bring any value to anyone.
"PendingDeprecationWarning = DeprecationWarning" costs nothing in term
of maintenance.

If you care, I would suggest to invest time in static analyzers like
pycodestyle, pylint, pyflakes, etc. Emit a warning with a low
priority, and let users make their own choices.

> We have `socket.error` for long time.

And it's perfectly fine, no?

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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] Removing PendingDeprecationWarning

[Inada Naoki]

On Fri, Mar 22, 2019 at 4:40 PM Victor Stinner  wrote:
>
>
> > More aggressively, I want to remove PendingDeprecationWarning class,
> > and `PendingDeprecationWarning = DeprecationWarning` for backward
> > compatibility.
>
> I'm not sure that I understand well. Do you want to remove the
> PendingDeprecationWarning builtin symbol, or just make it an alias to
> DeprecationWarning.
>
> I'm fine with "PendingDeprecationWarning = DeprecationWarning".
>

I meant an alias in builtin.

> IMHO your email title is misleading. You don't want to *remove*
> PendingDeprecationWarning, you only want to make it an alias to
> DeprecationWarning, right? In term of backward compatibility, it's
> very different :-)
>
> Victor

Yes.  It will be removed at some point, but not in near future.

But when when backward compatibility can be kept by alias,
we can be very lazy about removing it.

We have `socket.error` for long time.

Regards,
-- 
Inada Naoki  
___
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] Replacement for array.array('u')?

[Victor Stinner]

Hi,

Internally, CPython has a _PyUnicodeWriter which is an efficient way
to create a string but appending substrings or characters.
_PyUnicodeWriter changes the internal storage format depending on
characters code points (ascii or latin1: 1 byte/character, BMP: 2 b/c,
full UCS: 4 b/c). I tried once to expose it in Python, but I wasn't
convinced by performances. The overhead of method calls was quite
significant, and I wasn't convinced by "writer += str" performance
neither. Maybe I should try again. PyPy also has such object. It
avoids the "str += str" hack in ceval.c to avoid very poor performance
(_PyUnicodeWriter also uses overallocation which can be controlled
with multiple parameters to reduce the number of realloc).

Another alternative would be have to add a "strarray" type similar to
bytes/bytearray couple.

Is is what you are looking for? Or do you really need array.array API?

Victor

Le ven. 22 mars 2019 à 08:38, Greg Ewing  a écrit :
>
> A poster on comp.lang.python is asking about array.array('u').
> He wants an efficient mutable collection of unicode characters
> that can be initialised from a string.
>
> According to the docs, the 'u' code is deprecated and will be
> removed in 4.0, but no alternative is suggested.
>
> Why is this being deprecated, instead of keeping it and making
> it always 32 bits? It seems like useful functionality that can't
> be easily obtained another way.
>
> --
> Greg
> ___
> 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/vstinner%40redhat.com



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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] Removing PendingDeprecationWarning

[Victor Stinner]

Hi,

I agree to make PendingDeprecationWarning an alias to
DeprecationWarning. I never liked "PendingDeprecationWarning" name,
it's way too long to type :-D

Le ven. 22 mars 2019 à 03:45, Inada Naoki  a écrit :
> I want to stop using PendingDeprecationWarning for new deprecation.

I'm fine with that.

> More aggressively, I want to remove PendingDeprecationWarning class,
> and `PendingDeprecationWarning = DeprecationWarning` for backward
> compatibility.

I'm not sure that I understand well. Do you want to remove the
PendingDeprecationWarning builtin symbol, or just make it an alias to
DeprecationWarning.

I'm fine with "PendingDeprecationWarning = DeprecationWarning".

IMHO your email title is misleading. You don't want to *remove*
PendingDeprecationWarning, you only want to make it an alias to
DeprecationWarning, right? In term of backward compatibility, it's
very different :-)

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] Replacement for array.array('u')?

[Greg Ewing]

A poster on comp.lang.python is asking about array.array('u').
He wants an efficient mutable collection of unicode characters
that can be initialised from a string.

According to the docs, the 'u' code is deprecated and will be
removed in 4.0, but no alternative is suggested.

Why is this being deprecated, instead of keeping it and making
it always 32 bits? It seems like useful functionality that can't
be easily obtained another way.

--
Greg
___
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