[issue38420] defaultdict does not support parametric lambda
New submission from wang xuancong :
A very common use of defaultdict is that if the key exist, use the
corresponding mapped target, if the key does not exist, use the key itself.
However, current Python 2/3 defaultdict does not support parametric lambda
function:
>>> from collections import *
>>> aa=defaultdict(lambda t:t)
>>> aa
defaultdict( at 0x10a55c950>, {})
>>> aa[0]
Traceback (most recent call last):
File "", line 1, in
TypeError: () missing 1 required positional argument: 't'
>>>
I would like to suggest that use the dict's query key as the first argument in
the default lambda function. And use the dict itself as the 2nd argument in the
default lambda function (e.g., if the key exist, use the mapped target,
otherwise, use the size of the current defaultdict). I think that will make
Python much more powerful than any other programming language. Anyone can think
of any additional information for the default lambda function? Thanks!
--
messages: 354255
nosy: xuancong84
priority: normal
severity: normal
status: open
title: defaultdict does not support parametric lambda
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38420>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38315] Provide defaultdict variant that passes key to default_factory
wang xuancong added the comment: I agree with Mark Amery. The reason why defaultdict still exists given that everything can be achieved by subclassing the built-in dict is because of convenience. I suggest maybe Python developer can put it into low priority instead. -- nosy: +xuancong84 ___ Python tracker <https://bugs.python.org/issue38315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38503] bug: string search can find \n, but can NEVER find \r
New submission from wang xuancong :
If I load a file which contains "\r" and "\n", I can find "\n", but not "\r".
This behaviour is inconsistent in Python 3, but consistent in Python 2.
>>> open('./3cjkxdnw/accessibilityLog/1570181896323.csv',
>>> 'rb').read().count(b'\r')
88
>>> open('./3cjkxdnw/accessibilityLog/1570181896323.csv').read().count('\r')
0
>>> type(open('./3cjkxdnw/accessibilityLog/1570181896323.csv').read())
>>> type('\r')
Thanks!
--
messages: 354834
nosy: xuancong84
priority: normal
severity: normal
status: open
title: bug: string search can find \n, but can NEVER find \r
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue38503>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44028] Request for locals().update() to work, it is
New submission from wang xuancong :
In general, the ability to update local variables is very important and it
simplifies life tremendously. For example, in machine learning, it allows
saving/loading arbitrary-format datasets and arbitrary-structure neural
networks (NN) using a single line of code. In computer games, no matter how
many complex data structures are there, saving and loading can be done in a
single line.
Imagine you are game developer or a deep neural network (DNN) researcher, if
all local variables are serializable, then no matter how complicated your game
or your DNN structure is, saving the entire game or DNN (to STDOUT) can be
simply put into one line as `print(locals())`, and loading the entire game or
DNN (from STDIN) can be simply put into one line as
`locals().update(eval(sys.stdin.read()))`.
Currently, `globals().update(...)` takes immediate effect but
`locals().update(...)` does not work because Python documentation says:
> The default locals act as described for function locals() below:
> modifications to the default locals dictionary should not be
> attempted. Pass an explicit locals dictionary if you need to see
> effects of the code on locals after function exec() returns.
Why they design Python in such way is because of optimization and conforming
the `exec` statement into a function:
> To modify the locals of a function on the fly is not possible without
> several consequences: normally, function locals are not stored in a
> dictionary, but an array, whose indices are determined at compile time
> from the known locales. This collides at least with new locals added
> by exec. The old exec statement circumvented this, because the
> compiler knew that if an exec without globals/locals args occurred in
> a function, that namespace would be "unoptimized", i.e. not using the
> locals array. Since exec() is now a normal function, the compiler does
> not know what "exec" may be bound to, and therefore can not treat is
> specially.
Since `global().update(...)` works, the following piece of code will work in
root namespace (i.e., outside any function) because locals() is the same as
globals() in root namespace:
```
locals().update({'a':3, 'b':4})
print(a, b)
```
But this will not work inside a function.
I have explored a few ways of hacking updating locals() on Python 3, it seems
there is no way so far. The following piece of code seems to works:
```
def f1():
sys._getframe(1).f_locals.update({'a':3, 'b':4})
print(a, b)
f1()
```
However, that is because `sys._getframe(1)` is the root namespace, so
`sys._getframe(1).f_locals.update()` is essentially `globals().update()`.
>From the above Python developer documentation, I understand that in Python 2,
>local namespace lookup has 2 modes: optimized mode if there is no `exec`
>statement, un-optimized mode if there exists an `exec` statement. But in
>Python 3, `exec` becomes a function, so the compiler cannot determine which
>namespace optimization mode at compile time (because `exec` can be overridden
>or aliased into a different name). Therefore, Python 3 has only optimized
>namespace lookup. My suggestion is that whenever this optimized local
>namespace lookup fails, perform an un-optimized lookup (which will include
>locals()). This should solve the problem.
Do you have any other ideas or suggestions for doing this? Thanks!
--
components: Interpreter Core
messages: 392852
nosy: xuancong84
priority: normal
severity: normal
status: open
title: Request for locals().update() to work, it is
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue44028>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44028] Request for locals().update() to work, it is
wang xuancong added the comment: Of course, I am aware of that. As elite-level Python programmers, we should all be aware of security issues whenever we deal with exec() and eval(). -- ___ Python tracker <https://bugs.python.org/issue44028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44028] Request for locals().update() to work, it is
wang xuancong added the comment: Thanks @terry.reedy for your expert-level good comments! 1. "In Python 3, the one *implementation*, and its lookup mode, are fixed. The slower implementation was dropped because it was not thought worth the bother." If I remember correctly, the performance penalty due to the slower lookup mode is not quite significant, in most Python benchmarks, Python2 still performs much faster than Python3 because most codes that need speed does not contain exec/eval, so the slow mode won't affect in practice. 2. "When you invoke the save function while playing a game, I am imagine that the save function does not have access to and does not same the locals of whatever function was executing at the time you hit the save key. Rather a game and player states are serialized, and likely not in one line of code." I have personally tried this on one implementation of deep neural network using Tensorflow, it works pretty well, especially on saving the network parameters at every Nth epoch, or resuming training from a particular epoch. The biggest advantage is that it does not scale with network size or complexity, so the Python code size has a O(1) complexity with network size/complexity and that is a small constant O(1) as it does not involve any Python loop. In practice, you can select what to save/load, such as those not starting with '_'. -- ___ Python tracker <https://bugs.python.org/issue44028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44930] super-Matlab-style ranged list literal initialization
New submission from wang xuancong : Different from Python 2, Python 3 has removed the capability to create a list from a range. In Python 2, we can use range(1,100,2) to create a list [1, 3, 5, ..., 99], but in Python 3, we can only use list(range(1,100,2)) or [*range(1,100,2)] where the latter is even slower. I would like to propose to use something like [1:100:2] to initialize a list, moreover, you can use [1:100:2, 1000:1200:5, 5000:6000, :10] to create a list of multiple segments of ranges, i.e., [1,3,5,...,99,1000,1005,1010,...,1195,5000,5001,5002,...,5999,0,1,2,...,9]. Ranged list creation is quite useful and is often used in multi-thread/multi-processing scheduling or tracked sorting. This is especially useful in deep learning where you want to shuffle the training data but keep track of their corresponding labels. In deep RNN, where every training instance has a different length, after shuffling/sorting, you also need to keep track of their corresponding lengths information and etc. Thanks! -- components: Interpreter Core messages: 399707 nosy: xuancong84 priority: normal severity: normal status: open title: super-Matlab-style ranged list literal initialization type: enhancement ___ Python tracker <https://bugs.python.org/issue44930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44930] super-Matlab-style ranged list literal initialization
wang xuancong added the comment: Another lazy explanation not wanting to improve anything -- ___ Python tracker <https://bugs.python.org/issue44930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37780] A strange bug in eval() not present in Python 3
New submission from wang xuancong :
We all know that since:
[False, True, False].count(True) gives 1
eval('[False, True, False].count(True)') also gives 1.
However, in Python 2,
eval('[False, True, False].count(True)', {}, Counter()) gives 3, while
eval('[False, True, False].count(True)', {}, {}) gives 1.
Take note that a Counter is a special kind of defaultdict, which is again a
special kind of dict. Thus, this should not alter the behaviour of eval().
This behaviour is correct in Python 3.
--
components: Library (Lib)
messages: 349146
nosy: xuancong84
priority: normal
severity: normal
status: open
title: A strange bug in eval() not present in Python 3
type: behavior
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue37780>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36047] socket file handle does not support stream write
New submission from wang xuancong :
Python3 programmers have forgotten to convert/implement the socket file
descriptor for IO stream operation. Would you please add it? Thanks!
import socket
s = socket.socket()
s.connect('localhost', 5432)
S = s.makefile()
# on Python2, the following works
print >>S, 'hello world'
S.flush()
# on Python3, the same thing does not work
print('hello world', file=S, flush=True)
It gives the following error:
Traceback (most recent call last):
File "", line 1, in
io.UnsupportedOperation: not writable
Luckily, the stream read operation works, S.readline()
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 336035
nosy: xuancong84
priority: normal
severity: normal
status: open
title: socket file handle does not support stream write
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue36047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19522] A suggestion: python 3.* is not as convenient as python 2.*
New submission from wang xuancong:
Hi python developers,
I notice that one major change in python 3 is that you make 'print' as a
standard function, and it will require typing (). As you know, reading from and
writing to IO is a high frequency operation. By entropy coding theorem, you
should make your language having shortest code for doing that job. Typing a '('
requires holding SHIFT and pressing 9, the input effort is much higher. Also,
specifying IO has changed from >>* to file=*, which becomes more inconvenient.
I hope you can take a look at user's code and see what are the most commonly
used functions and try to shorten language codes for those functions. Assigning
shortest language codes to most frequently used functions will make python the
best programming language in the world.
Another suggestion is that 'enumerate' is also frequently used, hopefully you
can shorten the command.
Wang Xuancong
National University of Singapore
--
components: Interpreter Core
messages: 202400
nosy: xuancong84
priority: normal
severity: normal
status: open
title: A suggestion: python 3.* is not as convenient as python 2.*
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue19522>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
