[issue43143] Allow multiple assignment (i.e. tuple on LHS) in walrus operator
Paul Sokolovsky added the comment:
Thanks.
I would like to put this ticket in the context of other grammar-related
tickets/elaboration for the assignment operator:
https://bugs.python.org/issue42316 - allow foo[a:=1] instead of foo[(a:=1)]
https://bugs.python.org/issue42374 - allow (c := i for i in b) instead of ((c
:= i) for i in b)
https://bugs.python.org/issue42381 - allow {i := 0 for i in b} instead of {(i
:= 0) for i in b}
All of the above were implemented. Of course, allow parallel assignment, which
was previously disabled, is somewhat a bigger change then allowing
unparenthesized assignment usage. But from the grammar point of view, they are
of the same nature (using walrus-aware term at right place). The initial patch
I have on my hands is:
named_expression[expr_ty]:
-| a=NAME ':=' ~ b=expression { _Py_NamedExpr(CHECK(expr_ty,
_PyPegen_set_expr_context(p, a, Store)), b, EXTRA) }
+| a=star_targets ':=' ~ b=expression { _Py_NamedExpr(CHECK(expr_ty,
_PyPegen_set_expr_context(p, a, Store)), b, EXTRA) }
And let's review the 'foo[(a := 1)]' case from more angles. C had assignment as
expression from the very beginning, but in all fairness, I never saw "foo[a =
1]" in my whole life (well, maybe in https://www.ioccc.org/ submissions). But
we see that with Python, people are not too shy to use that. And they even
submit issues like "hey, I don't want to write foo[(a := 1)], I want to write
foo[a := 1] !" And they don't get replies like "you know, doing assignment in
index would hamper readability/maintainability; and those extra parens are
there exactly to hint you more about this fact". Instead, the case is getting
acked and fixed.
So, under such circumstances, I don't think that writing "min((a, b) := (b,
a))" should be considered "much worse" than "foo[a := 1]", and should be kept
disallowed (as again, fix for both is of the same nature).
--
___
Python tracker
<https://bugs.python.org/issue43143>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43143] Allow multiple assignment (i.e. tuple on LHS) in walrus operator
Change by Paul Sokolovsky : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue43143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43143] Allow multiple assignment (i.e. tuple on LHS) in walrus operator
New submission from Paul Sokolovsky : Currently (CPython 3.10.0a4) having a tuple on left-hand side of assignment expression/operator (aka walrus operator) is not allowed: >>> ((a, b) := (1, 2)) File "", line 1 ((a, b) := (1, 2)) ^ SyntaxError: cannot use assignment expressions with tuple As far as can tell, there's no explicit consideration of this case in the PEP572. There closest it has is under the https://www.python.org/dev/peps/pep-0572/#differences-between-assignment-expressions-and-assignment-statements section, "Iterable packing and unpacking (both regular or extended forms) are not supported". But note that the usecase presented above is better seen as "parallel assignment", not as "iterable unpacking". Next issue: PEP572 puts heavy emphasis on the "named expression" usecase. I would like to emphasize, that "naming an expression" seems like *just one of usecases* for assignment operator. First and foremost assignment operator is, well, assignment. With that in mind, ((a, b) := (1, 2)) is compatible with "naming expressions" idea, it "gives names" to multiple expressions at once. There's a temptation to suggest that the above could be rewritten as: ((a := 1), (b := 2)) , and for the "naming" usecase, that would be true. But as noted above, "naming" is just *one* of the usecases. Following can't be "sequentialized" like that: ((b, a) := (a, b)) And for as long as someone considers the following acceptable: func(a := val) There's little point to prohibit the following: min((b, a) := (a, b)) And that's the main argument - consistency between assignment statement and assignment operator. For as long as this is allowed: a, b = b, c it makes sense to allow: ((a, b) := (b,c)) (Extra parens account for different in grammar and precedence for the operator). This issue is posted to capture discussion initially posted to python-ideas/python-dev: https://mail.python.org/archives/list/python-id...@python.org/thread/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/ https://mail.python.org/archives/list/python-id...@python.org/thread/X3LNCCO6PHTLAQXHEAP6T3FFW5ZW5GR5/ https://mail.python.org/archives/list/python-...@python.org/thread/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/ , to serve as a reference to whoever may be searching the bugtracker for this case. -- components: Interpreter Core messages: 386551 nosy: pfalcon priority: normal severity: normal status: open title: Allow multiple assignment (i.e. tuple on LHS) in walrus operator ___ Python tracker <https://bugs.python.org/issue43143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
Paul Sokolovsky added the comment:
> the idea was proposed purely to "close a gap"
That pinpoints it well. I was just writing a tutorial on implementing custom
import hooks, with the idea to show people how easy it to do it in Python. As
first step, I explained that it's bad idea to do any transformations on surface
representation of a program. At the very least, it should be converted to token
stream. But then I found that I need to explain that we need to convert it
back, which sounds pretty weird and undermines the idea:
def xform(token_stream):
for t in token_stream:
if t[0] == tokenize.NAME and t[1] == "function":
yield (tokenize.NAME, "lambda") + t[2:]
else:
yield t
with open(filename, "rb") as f:
# Fairly speaking, tokenizing just to convert back to string form
# isn't too efficient, but CPython doesn't offer us a way to parse
# token stream so far, so we have no choice.
source = tokenize.untokenize(xform(tokenize.tokenize(f.readline)))
mod = type(imphook)("")
exec(source, vars(mod))
return mod
Having written that comment, I thought I could as well just make one more step
and monkey-patch "ast" for parse_tokens() function - I'll need to explain that,
but the explanation probably wouldn't sound worse than the explanation above.
And then it was just one more step to actually submit patch for
ast.parse_tokens(), and that's how this ticket was created!
--
___
Python tracker
<https://bugs.python.org/issue42729>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
Paul Sokolovsky added the comment: > There is a considerable tension on exposed parts of the compiler pipeline for > introspection and other capabilities and our ability to do optimizations. > Given how painful it has been in the past to deal with this, my view is to > avoid exposing as much as possible anything in the compiler pipeline, so we > don't shoot ourselves in the foot in the future if we need to change stuff > around. That's somewhat extreme outcome when a problem is known and understood, but the best solution is deemed not doing anything. But the problem of "doing it wrong" definitely known and exists. One known way to address it is to design generic interfaces and implement them. This ticket is exactly about that - defining a missing interface for a parser in Python. It's not about *the* CPython's C parser and its peculiarities. (But even it fits with the generic interface proposed.) -- ___ Python tracker <https://bugs.python.org/issue42729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
Paul Sokolovsky added the comment: > but the thing I don't quite get is the use case. And if that went unanswered: the usecase, how I'd formulate it, is to not expose CPython historical implementation detail of "tokenize" being disconnected from the rest of the language processing infrastructure, and make them learn tricks like needing to go back to character program form if they ever start to use "tokenize", but let it all integrate well into single processing pipeline. -- ___ Python tracker <https://bugs.python.org/issue42729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
Paul Sokolovsky added the comment: > What prevents you from using ast.parse(tokenize.untokenize(token_stream))? That's exactly the implementation in the patch now submitted against this issue. But that's the patch for CPython, the motive of the proposal here is to establish a standard API call for *Python*, which different implementation can implement how they like/can/need. > Also, tokens -> AST is not the only disconnected part in the underlying > compiler. We should address them, one by one. > Stuff like AST -> Symbol Table Kinda yes, again, based on CPython implementation history, we have only source -> Symbol table (https://docs.python.org/3/library/symtable.html). Would be nice to address that (separately of course). > AST -> Optimized AST Yes. PEP511 touched on that, but as it-as-a-whole was rejected, any useful sub-ideas from it don't seem to get further progress either (like, being able to disable some optimizations, and then maybe even exposing them as standalone passes). > I'd also suggest moving the discussion to the Python-ideas, for a much > greater audience. That's how I usually do, but I posted too much there recently. I wanted to submit a patch right away, but noticed that standard commit message format is "bpo-X: ...", so I created a ticket here to reference in the commit. -- ___ Python tracker <https://bugs.python.org/issue42729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
Change by Paul Sokolovsky : -- keywords: +patch pull_requests: +22773 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23922 ___ Python tracker <https://bugs.python.org/issue42729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
New submission from Paul Sokolovsky : Currently, it's possible: * To get from stream-of-characters program representation to AST representation (AST.parse()). * To get from AST to code object (compile()). * To get from a code object to first-class function to the execute the program. Python also offers "tokenize" module, but it stands as a disconnected island: the only things it allows to do is to get from stream-of-characters program representation to stream-of-tokens, and back. At the same time, conceptually, tokenization is not a disconnected feature, it's the first stage of language processing pipeline. The fact that "tokenize" is disconnected from the rest of the pipeline, as listed above, is more an artifact of CPython implementation: both "ast" module and compile() module are backed by the underlying bytecode compiler implementation written in C, and that's what connects them. On the other hand, "tokenize" module is pure-Python, while the underlying compiler has its own tokenizer implementation (not exposed). That's the likely reason of such disconnection between "tokenize" and the rest of the infrastructure. I propose to close that gap, and establish an API which would allow to parse token stream (iterable) into an AST. An initial implementation for CPython can (and likely should) be naive, making a loop thru surface program representation. That's ok, again, the idea is to establish a standard API to be able to go tokens -> AST, then individual Python implementation can make/optimize it based on their needs. The proposed name is ast.parse_tokens(). It follows the signature of the existing ast.parse(), except that first parameter is "token_stream" instead of "source". Another alternative would be to overload existing ast.parse() to accept token iterable. I guess, at the current stage, where we try to tighten up type strictness of API, and have clear typing signatures for API functions, this is not favored solution. -- components: Library (Lib) messages: 383680 nosy: BTaskaya, pablogsal, pfalcon, serhiy.storchaka priority: normal severity: normal status: open title: tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42559] random.getrandbits: Should it be explicit that it returns unsigned/non-negative integer?
Paul Sokolovsky added the comment: Raymond Hettinger: Thanks for acking it would be a useful change! ZackerySpytz: Thanks for making a patch! -- ___ Python tracker <https://bugs.python.org/issue42559> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42559] random.getrandbits: Should it be explicit that it returns unsigned/non-negative integer?
New submission from Paul Sokolovsky : Current docs for random.getrandbits() ( https://docs.python.org/3/library/random.html#random.getrandbits ) read (3.9.1rc1 at the top of the page): Returns a Python integer with k random bits. This method is supplied with the MersenneTwister generator and some other generators may also provide it as an optional part of the API. When available, getrandbits() enables randrange() to handle arbitrarily large ranges. So, based that it talks about "bits", it's easy to imagine that the result is unsigned. But it's interesting that it mentions "a Python integer", not even just "integer". And Python integers are known to be signed. So I'd say, there's enough of ambiguity in there, and would be nice to explicitly specify that it's "unsigned (non-negative) Python integer". If there's interest for the background of concern, some implementations may have "small" and "large" integers underlyingly (which used to be exposed at the user-level in Python2). "Small" integers would be cheaper, but of course, they would be signed. So, at certain value of getrandbits() parameter, there may be a temptation to use up a sign bit of a small integer, instead of going straight to allocating expensive large integer. It should be clear this is NOT a valid "optimization", and result should be always non-negative. -- messages: 382434 nosy: pfalcon priority: normal severity: normal status: open title: random.getrandbits: Should it be explicit that it returns unsigned/non-negative integer? versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42559> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > We may be possible to replace bytecode from `STORE_GLOBAL _cnt; LOAD_GLOBAL > _cnt` into `DUP_TOP; STORE_GLOBAL _cnt`. Sounds good, and that's why I personally care about the "STORE" case, and the patch I submit touches only it, which would affect only cases when explicit "global var" declarations are used, which aren't frequent. I definitely would be too shy to submit a patch for more LOAD_* cases, though I may image why people may want that still. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: Absolutely should be able to optimize namespace access. The fact that namespace is a dict is an implementation detail, it's still inefficient even with all those version counters and inline caches. Ironically, to let people prototype better, more efficient ways to deal with namespace access, it should be possible to override an object used as a namespace. Thanks for making that much more complicated. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > exec() function is currently quite clear A recent case: https://bugs.python.org/issue38316, co_stacksize was quite clear what it is. Turned out, a bug in the documentation (likely, just someone forgot to update it to the actual code). That's just one case, there're tons of bugs in the docs. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > Namespace performances are really critical for overall Python performances. Yeah, that's why I'd like for myself and other people to make it easy to explore the behavior of namespace lookups, to see how to optimize them. > You're free to fork Python and modify the C code to implement your use case, > to study Python internals. Thanks, already done. I'm now looking for a way to share those studies with other people, who won't patch and compile CPython. So, no worries, I've already lost, I need that fix yesterday, in actual versions of CPython deployed around the world. The rest if just idea that bugs which aren't fixed, persist; and the very interesting case of decision making by CPython core developers. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > Paul: you're are in front of 3 core developers who are rejecting your feature > request. But no, it's not my feature request. There were 2 tickets by at least 2 people. I just saw my case to be similar to cases of those people, so instead of creating duplicate bug reports, I chimed in, to show the general issue: various name-related opcodes don't treat namespace objects consistently. And if I'm in front on 3 core developers here, then only because someone's Rubber Ducky (https://en.wikipedia.org/wiki/Rubber_duck_debugging) took a good vacation. Because I may imagine following "debugging session": - Hey Ducky, some time ago I hacked on one project. As you know, I'm a core developer, so I kinda can add things on my whim, so I added some stuff to CPython core for that project, not consistent, not complete. Since then, I lost interest in my project, and as you can imagine, couldn't care less about the code in the core. The problem? It was almost 8 years ago. People discovered those features, and came to use on them. Not only that, they raise heads and demand it to be implemented more thoroughly and consistently. So, don't you think now would be good time to punish them and just rip that code out? - You say how could I possible to do that on my own? No worries, I have 2 more buddies vouching for me, we core developers never let each other down. - You're saying that removing features after 8 years is problematic? No worries, we can always say it was a regression from just 3 years ago. - Hey Ducky, there's a more problem still, there's a particularly obnoxious dude, who initially tried to argue need for adding a feature based on my 8-year old code. If we support stuff in LOAD_GLOBAL, he says, then it should be piece of cake to support it in STORE_GLOBAL, which is called much less frequently. But we got him into the cold with a news of removal that 8-year code. Still he can't calm down, and changing tactics arguing that due to the way that globals are used at the module level (as locals too), then STORE_GLOBAL should behave consistently with STORE_NAME, tossing some pretty simple exec() code showing inconsistency. Should we just ignore him, or go for total punishment and make it "consistent" just the same as above, by removing support in STORE_NAME, instead of adding to STORE_GLOBAL? Now, that code is 16 years old. Do you think we can go for a twist like that? -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > you ask to modify Python so you can pass dict subclasses as namespaces and > expect CPython to respect the mapping protocol But no, per your own account, you made noticeable, though not complete, code changes in that direction. The only thing I'm saying "now that it's all there, it's only logical to fix the missing parts, about which people report issues". While you suddenly come up with "alternative" solution - throw it all away. And I always just took your word for it, but now did some git logging/blaming. So, LOAD_GLOBAL handling of dict subclasses was introduced by you in https://github.com/python/cpython/commit/b0b224233e481d979430a54d257d871424ff19fb , in 2012, almost 8 years ago. And what about STORE_NAME handling? I traced that to https://github.com/python/cpython/commit/214b1c3aaea3e83302df9ea37a37b3c7548b92b1 of 2004. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: Ok, so the patch for my usecase (STORE_GLOBAL) is vividly trivial, so to go thru the full circle, I posted it: https://github.com/python/cpython/pull/18033 . -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36220] LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently
Change by Paul Sokolovsky : -- pull_requests: +17429 pull_request: https://github.com/python/cpython/pull/18033 ___ Python tracker <https://bugs.python.org/issue36220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: s/only our own usecase/only your own usecase/ (missing "y" typo) -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > Later, I closed my pysandbox beause it was "broken by design": https://lwn.net/Articles/574215/ Thanks for the link, insightful. Still unclear, by design of what it's broken ;-). > Paul Sokolovsky wrote in bpo-36220 than his idea is also to implement a > sandbox Depends on the definition of "sandbox". If it's "But I was contacted by different companies interested to use pysandbox in production on their web application. So I think that there is a real need to execute arbitrary untrusted code." (re: https://lwn.net/Articles/574323/). Then no, I definitely not developing such a "sandbox". If by "sandbox" you mean "ability to override some namespacing rules used by Python", then yep, I, and other folks (according to these >1 issue reports) interested in that. It's unclear why demise of your particular project should affect all other possible projects interested in dealing with namespacing matters. I for example interested in study of some properties of corpus of Python code. I can understand your claim that you "own" the partial features you introduced, but claiming them to be useful for only our own usecase is somewhat ..., well, short-sighted, just as claiming that all such uses should cease and desist is as insightful as claiming that, for example, list comprehensions are useless because you faced a case when one needs to be rewritten as explicit loop. > IMHO we should reject dict subclasses to make Python (especially ceval.c) > more efficient. I'm afraid efficiency story for CPython is irrecoverably lost, unless someone secretly works on adding JIT to it, but as we know, JIT work happily happens outside of it, in multiples. CPython still can either serve as a common platform for prototyping and experimentation, or complicate that by a committee fiat. Because the current situation is that CPython is too dynamic to be "slow", but not enough dynamic to perform useful instrumentation easily. For example, to comfortably do study on the proportions of actual usage of various "overdynamic" features. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > I agree with Terry, the moment you pass a dict subclass to exec you are out > of contract. If any, we may need to sanitize the input to exec, although I > don't think is worth paying the performance price for that. exec() params are already checked, as a seconds param, only dict or dict subclasses are accepted. Seems like good enough contract. > Paul, I don't know if you are being sarcastic here so I will assume that you > are not but in case you are, I suggest you stop as this violates our CoC. I am not, and please stop your accusations, that violates CoC. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: > The doc for exec says globals "must be a dictionary (and not a subclass of > dictionary)" Docs are full of mistakes and outdated information. Fixing STORE_GLOBAL case from https://bugs.python.org/issue36220#msg359046 would be trivial and cheap re: overheads. And useful, yeah. And the gentleman who submitted the other ticket argues that: > but the inconsistency between LOAD_NAME and LOAD_GLOBAL definitely seems > wrong. Which is easy to agree with, though there're more concerns re: runtime overhead. -- ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32615] Inconsistent behavior if globals is a dict subclass
Paul Sokolovsky added the comment: Some smart maintainer closed https://bugs.python.org/issue36220 as a duplicate of this one. That ticket might have more details of the underlying issues. -- nosy: +pfalcon ___ Python tracker <https://bugs.python.org/issue32615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36220] LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently
Paul Sokolovsky added the comment:
> I wanted to write a sandbox for Python.
Sandbox indeed, it is.
class NS(dict):
def __setitem__(self, k, v):
if not isinstance(v, type(lambda: 0)):
raise RuntimeError("Global variables considered harmful")
globals = NS()
exec("foo = 1", globals)
But then:
exec("""
global foo
foo = "watch me escaping your sandboxes"
""", globals)
This is due to STORE_GLOBAL not handling dict subclasses, unlike STORE_NAME.
While @Kevin Shweh's issue with LOAD_NAME, and @vstinner's concerns of adding
yet another branch to LOAD_NAME implementation may be one matter, issue with
STORE_GLOBAL is both related and somewhat different. STORE_GLOBAL's should be
relatively infrequent, so adding another branch to it unlikely will be
quantifiable in performance. But lack of its support disallows to write to
tools which police/constrain Python's overdynamicity, which is useful in the
age.
Anyway, I decided to not open a separate ticket for this, but add here. Fairly
speaking, as long as work to support dict subclasses as globals/locals started,
the only reasonable way forward seems to implement it completely.
--
___
Python tracker
<https://bugs.python.org/issue36220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36220] LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently
Change by Paul Sokolovsky : -- nosy: +pfalcon title: LOAD_NAME and LOAD_GLOBAL handle dict subclasses for globals() differently -> LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently ___ Python tracker <https://bugs.python.org/issue36220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38316] docs: Code object's "co_stacksize" field is described with mistake
New submission from Paul Sokolovsky :
CPython's Data Model -> Internal types -> Code objects, direct link as of
version 3.7 is:
https://docs.python.org/3.7/reference/datamodel.html?highlight=co_stacksize#index-55
, states following:
* "co_nlocals is the number of local variables used by the function (including
arguments);"
* "co_stacksize is the required stack size (including local variables);"
However, practical checking shows that co_stacksize is the required stack size
WITHOUT local variables. One could argue about the meaning of "local variables"
in the description of co_stacksize above, saying that what is meant is
temporary stack variables of something. That's why I quoted above co_nlocals
description too, it clearly shows that local variebles are local function
variables (include functions args), and nothing else.
Code to reproduce:
==
def func():
a = 1
b = 2
c = 3
print("co_stacksize", func.__code__.co_stacksize)
print("co_nlocals", func.__code__.co_nlocals)
==
Result of running:
==
$ python3.7 script_under_test.py
co_stacksize 1
co_nlocals 3
==
Clearly, co_stacksize doesn't include the size of local vars, or it would have
been larger than co_nlocals in printout.
--
assignee: docs@python
components: Documentation
messages: 353508
nosy: docs@python, pfalcon
priority: normal
severity: normal
status: open
title: docs: Code object's "co_stacksize" field is described with mistake
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38316>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12345] Add math.tau
Paul Sokolovsky added the comment: What about rounding pi to 3 (and tau to 6)? https://en.wikipedia.org/wiki/Indiana_Pi_Bill (and I'm sure we can find a cute video about how cool to have pi as 3 to add it to the docs). -- nosy: +pfalcon ___ Python tracker <http://bugs.python.org/issue12345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26899] struct.pack_into(), struct.unpack_from() don't document support for negative offsets
New submission from Paul Sokolovsky: See https://docs.python.org/3/library/struct.html#struct.pack_into https://docs.python.org/3/library/struct.html#struct.unpack_from Actual source contains code like: if (offset < 0) offset += vbuf.len; to allow specify offsets from the end of a buffer. -- assignee: docs@python components: Documentation messages: 264590 nosy: docs@python, pfalcon priority: normal severity: normal status: open title: struct.pack_into(), struct.unpack_from() don't document support for negative offsets versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue26899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1103213] Adding a recvexactly() to socket.socket: receive exactly n bytes
Changes by Paul Sokolovsky : -- nosy: +pfalcon ___ Python tracker <http://bugs.python.org/issue1103213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24449] Please add async write method to asyncio.StreamWriter
Paul Sokolovsky added the comment: Thanks for the response. > and an API with more choices is not necessarily better. I certainly agree, and that's why I try to implement MicroPython's uasyncio solely in terms of coroutines, without Futures and Transports. But I of course can't argue for dropping Transports in asyncio, so the only argument I'm left with is consistency of API (letting use coroutines everywhere). > I'm sure this has come up before, I could've sworn it was you, sorry if it > wasn't. No, I brought issue of Futures dependency (yes, that was wide and long discussion), then about yielding a coroutine instance as a way to schedule it. But during the time I'm on python-tulip, I didn't remember someone bringing up issue of asymmetry between read & write, but I would imagine someone would have done that before me. (Which might hint that the issue exists ;-) ). > the common mistake (amongst beginners) of forgetting the "yield from" or > 'async' would be much harder to debug So, this is not first time you provide this argument for different cases, one would think that this pin-points pretty serious flaw in the language and it's priority to find a solution for it, and yet PEP3152 which does exactly that was rejected, so maybe it's not that *serious*. Indeed, it's common sense that it's possible to make a hard to debug mistake in any program, and in any concurrent program (doesn't matter of which paradigm) it's order of magnitude easier to do one and harder to debug respectively. But asyncio does have tools to debug such issue. And one would think that easiest way to preclude mistake is to avoid inconsistencies in the API. I know there's a very find balance between all the arguments, and only you can know where it lies, but kindly accept external feedback that the above explanation (syntax is more prone to mistakes) looks like universal objectivized rejection in rather subjective cases. What saddens me here is that this decision puts pretty high lower bound for asyncio memory usage (and I tried hard to prove that asyncio is suitable paradigm even for smaller, IoT-class devices). It's also hard to argue that Python isn't worse than Go, Rust and other new kids on the block - because indeed, how one can argue that, if even the language author uses argument "language syntax, while exists, isn't good enough to do the obvious things". -- ___ Python tracker <http://bugs.python.org/issue24449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24449] Please add async write method to asyncio.StreamWriter
Paul Sokolovsky added the comment: No, I haven't brought this "many times before". Discussion on the mailing list last week was first time I brought up *this* issue. But it's indeed not the first time I provide feedback regarding various aspects of asyncio, so I wonder if this issue was closed because of "this" in "this issue" or because of "many times before"... > If you need awrite(), it's a two-line helper function you can easily write > yourself. Yes, and I have it, but I don't see how that helps anybody else. If it's 2-liner, why don't you want to add it? Can there please be discussion of the arguments provided in the description? -- ___ Python tracker <http://bugs.python.org/issue24449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24449] Please add async write method to asyncio.StreamWriter
New submission from Paul Sokolovsky:
This issue was brought is somewhat sporadic manner on python-tulip mailing
list, hence this ticket. The discussion on the ML:
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/knMvVGxp2WsJ
(all other messages below threaded from this)
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/lGqT54yupOIJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/U0NBC1jLGSgJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/zIx59jj8krsJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/zSpjGKv23ioJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/3mfGI8HIe_gJ
https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/rM4fyA9qlY4J
Summary of arguments:
1. This would make such async_write() (a tentative name) symmetrical in usage
with read() method (i.e. be a coroutine to be used with "yield from"/"await"),
which certainly reduce user confusion and will help novices to learn/use
asyncio.
2. write() method is described (by transitively referring to
WriteTransport.write()) as "This method does not block; it buffers the data and
arranges for it to be sent out asynchronously." Such description implies
requirement of unlimited data buffering. E.g., being fed with 1TB of data, it
still must buffer it. Bufferings of such size can't/won't work in practice -
they only will lead to excessive swapping and/or termination due to out of
memory conditions. Thus, providing only synchronous high-level write operation
goes against basic system reliability/security principles.
3. The whole concept of synchronous write in an asynchronous I/O framework
stems from: 1) the way it was done in some pre-existing Python async I/O
frameworks ("pre-existing" means brought up with older versions of Python and
based on concepts available at that time; many people use word "legacy" in such
contexts); 2) on PEP3153, which essentially captures ideas used in the
aforementioned pre-existing Python frameworks. PEP3153 was rejected; it also
contains some "interesting" claims like "Considered API alternatives -
Generators as producers - [...] - nobody produced actually working code
demonstrating how they could be used." That wasn't true at the time of PEP
writing (http://www.dabeaz.com/generators/ , 2008, 2009), and asyncio is
actually *the* framework which uses generators as producers.
asyncio also made a very honorable step of uniting generators/coroutine and
Transport paradigm - note that as PEP3153 shows, Transport proponents
contrasted it with coroutine-based design. But asyncio also blocked (in both
senses) high-level I/O on Transport paradigm. What I'm arguing is not that
Transports are good or bad, but that there should be a way to consistently use
coroutine paradigm for I/O in asyncio - for people who may appreciate it. This
will also enable alternative implementations of asyncio subsets without
Transport layer, with less code size, and thus more suitable for constrained
environments.
Proposed change is to add following to asyncio.StreamWriter implementation:
@coroutine
def async_write(self, data):
self.write(data)
I.e. default implementation will be just coroutine version of synchronous
write() method. The messages linked above discuss alternative implementations
(which are really interesting for complete alternative implementations of
asyncio).
The above changes are implemented in MicroPython's uasyncio package, which
asyncio subset for memory-constrained systems.
Thanks for your consideration!
--
components: asyncio
messages: 245336
nosy: gvanrossum, haypo, pfalcon, yselivanov
priority: normal
severity: normal
status: open
title: Please add async write method to asyncio.StreamWriter
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue24449>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"
New submission from Paul Sokolovsky: Under https://docs.python.org/3/howto/descriptor.html#functions-and-methods , there're several references to unbound methods (including in expected output from the interpreter). As known, unbound methods are gone in Python3, so seeing those are confusing. (I didn't sharply know that unbound methods are gone from Py3, so was pretty confused by the examples there, comparing them with actual output of Cpython 3.4). -- assignee: docs@python components: Documentation messages: 238468 nosy: docs@python, pfalcon priority: normal severity: normal status: open title: docs.python.org/3/howto/descriptor.html still refers to "unbound methods" versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue23702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21511] Thinko in Lib/quopri.py
Paul Sokolovsky added the comment: This is minor issue indeed, uncovered when trying to run quopri.py with MicroPython http://micropython.org . I now worked around this on MicroPython side, but otherwise I set to report any issues I've seen with MicroPython porting, in the hope that MicroPython effort is good member of Python community. If the original report is unclear, feel free to point to any vague spots, and I'll elaborate on it. Thanks. -- ___ Python tracker <http://bugs.python.org/issue21511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21511] Thinko in Lib/quopri.py
New submission from Paul Sokolovsky: Lib/quopri.py for version 3.3..3.5-tip contains following code: ESCAPE = b'=' ... line = input.readline() if not line: break i, n = 0, len(line) if n > 0 and line[n-1:n] == b'\n': ... elif i+1 < n and line[i+1] == ESCAPE: So, ESCAPE is defined as bytes, we see that "line" is read as bytes, and characters are accessed using idiom like "line[n-1:n]", but then it uses "line[i+1]", which returns int and thus will never be equal to ESCAPE. I'm not sure what exact semantic condition that branch represents, for me it looks like "==" sequence to be decoded as "=". But I don't see such encoding variant in http://en.wikipedia.org/wiki/Quoted-printable . Either way, replacing that condition with "and False", still passes test_quopri.py -- components: Library (Lib) messages: 218618 nosy: pfalcon priority: normal severity: normal status: open title: Thinko in Lib/quopri.py type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue21511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21464] fnmatch module uses regular expression with undefined result to perform matching
Paul Sokolovsky added the comment: I see, so it's my misreading of the "re" module docs. I kinda thought that "x" in "(?x)" means "any single-character flag of set (?aiLmsux)". I was wrong, it is the specific literal flag. Also, rereading it again, the doc says "the letters set the corresponding flags: [list of flags], for the entire regular expression." So, my report is invalid. Just to give some context, I hit this when porting fnmatch.py to MicroPython (http://micropython.org/), which doesn't use native CPython SRE, but instead system PCRE. Well, it would be nice if stdlib maintained kind of compatibility with original PCRE semantics, but that's kinda wishful thinking, we'll work it around on our side. Closing this. -- resolution: -> works for me status: open -> closed ___ Python tracker <http://bugs.python.org/issue21464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21464] fnmatch module uses regular expression with undefined result to perform matching
Changes by Paul Sokolovsky : -- title: fnmatch module uses undefined regular expression to perform matching -> fnmatch module uses regular expression with undefined result to perform matching ___ Python tracker <http://bugs.python.org/issue21464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21464] fnmatch module uses undefined regular expression to perform matching
New submission from Paul Sokolovsky: fnmatch.translate() ends with: return res + '\Z(?ms)' However, https://docs.python.org/3.4/library/re.html#regular-expression-syntax states: Note that the (?x) flag changes how the expression is parsed. It should be used first in the expression string, or after one or more whitespace characters. If there are non-whitespace characters before the flag, the results are undefined. Hence, fnmatch uses undefined pattern, and indeed, it fails with alternative Perl-compatible regular expression implementations (specifically, PCRE, which appear to do something like apply flag at the point of its occurrence). -- components: Library (Lib) messages: 218198 nosy: pfalcon priority: normal severity: normal status: open title: fnmatch module uses undefined regular expression to perform matching versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue21464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21365] asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead
Paul Sokolovsky added the comment: Based on discussion https://groups.google.com/forum/#!topic/python-tulip/zfMQIUcIR-0 . That discussion actually questions the grounds of such Task behavior, and points it as a violation of "Explicit is better than implicit" principle, and as inconsistent behavior wrt to similar objects in Python stdlib (threads, processes, etc.) This ticket however assumes that there're very good reasons for such behavior, and/or it just should be accepted as API idiosyncrasy which is late to fix, and just tries to make sure that docs are not culprit for mismatching user expectations. -- ___ Python tracker <http://bugs.python.org/issue21365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21365] asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead
New submission from Paul Sokolovsky: It caused me a big surprise that asyncio.Task object automatically schedules itself in the main loop for execution upon creation (i.e. in constructor). Nowhere in the main reference part of section "18.5.2.4. Task" (https://docs.python.org/3.5/library/asyncio-task.html#task) does it mention that fact. Vice versa, it explicitly says that Task is merely "A coroutine object wrapped in a Future.", which surely sets grounds for surprise when finding that Task is not just coroutine wrapped in Future, but exhibits extra behavior unexpected of plain Future. Docs cursorily mention this property of Task outside main reference section for it. Specifically: 1) "18.5.2.1. Coroutines", end of intro section: "In the case of a coroutine object, there are two basic ways to start it running: call yield from coroutine from another coroutine (assuming the other coroutine is already running!), or convert it to a Task." I would argue that this is way too cursorily and doesn't put strong enough emphasis on the property of self-scheduling, to catch attention of novice or casual reader. For example, my entailments after reading the passage above are: "... or convert it to a Task, to schedule it in a loop [explicitly], because a coroutine can't be scheduled in a loop directly, but Task can be". 2) Very end of subsection "18.5.2.4.1. Example: Parallel execution of tasks", a short line squeezed between colored example block and new section heading - a place where some user will miss it outright: "A task is automatically scheduled for execution when it is created." Based on case study above, I would like to propose: 1). In section "18.5.2.4. Task", in class description, make unmissable fact that instantiating an object makes it scheduled. For example, append after: "A coroutine object wrapped in a Future. Subclass of Future." following: "Instantiating object of this class automatically schedules it to be run in an event loop specified by 'loop' parameter (or default event loop)." 2) Ideally, update 2 excerpts above to convey more explicit information, and be more visible (for case 2, for example, move it before the example, not after). -- assignee: docs@python components: Documentation messages: 217272 nosy: docs@python, pfalcon priority: normal severity: normal status: open title: asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue21365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Paul Sokolovsky added the comment:
Martin:
> People might expect that array.array('i', 3) creates an array with the single
> value 3.
I don't know which people would expect that. Personally I recognize the need to
create an empty array of of given size, and have read the docs for builtin
"bytearray" type, and expect extension type array.array to work the same. I'd
even say that I found any other expectations ungrounded, in particular, a way
to create an array of single int is obviously bytearray([3]) or
array.array('i', [3]).
Anyway, as I say in "2014-04-13 15:29" comment, I'm only glad to follow with
PEP467 changes. Unfortunately, I don't seem to be able to update initial ticket
description with updated proposal.
> array.array('i', len=3)
The whole scope of this ticket is to have consistent API between bytearray and
array.array. So, the only way I could suggest (or back) the above is if PEP467
was changed too, and as you suggest, I don't do that. (I personally also
dislike overuse of keyword args.)
> In any case, it is unlikely that anything will be done with this issue unless
> you provide a patch (and that still would be no guarantee that somebody
> accepts it).
The ending is the saddest. As I mentioned, the best outcome I could imagine of
such reports is that people who consider changing builtin types to also
consider obvious stdlib counterparts too. (There's another issue - stdlib is
indeed enormous, so it would be nice to separate it (speculatively) into
["builtin types/lib"], "core stdlib", and "extended stdlib". There's clear
difference between array module and for example unittest or logging.
Thanks for hint re: mailing Nick Coghlan - nice to know that's acceptable,
that's certainly easier than figuring out which mailing list to use and then to
follow it. (I see that Nick is in noselist of this ticket, but I guess I'll
mail him anyway to have my conscience clear that I did everything to make
Python better (== more consistent)).
--
___
Python tracker
<http://bugs.python.org/issue21180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Paul Sokolovsky added the comment:
@Terry J. Reedy:
Thanks for the pointer. My inital response is , another bloating of
namespace. But I'm adjusting.
But that PEP shows the issue with all that activity: CPython stdlib got so big
and bloated, that it lives its own life and people consider it normal. So,
there're PEPs to perfectalize bytearray, without paying attention to the fact
that array.array('B') is pretty much the same thing, but apirots (cf. bitrot)
behind it.
So, following PEP467, this request should be updated to call for
array.array.zero(typecode, size) factory method. Note that it would need to
take 2 arguments to follow array.array API. Is that good or bad? IMHO, not much
worse than introducing separate factory method at all. But again, author of
PEP467 should rather consider how those proposals extend to other related types.
If you participate in the discussion of the PEP, I'd appreciate if shared there
link to this ticket - I'm not in loop of general CPython development and have
limited resources to learn/follow them. Thanks.
--
___
Python tracker
<http://bugs.python.org/issue21180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Paul Sokolovsky added the comment:
> >>> array.array('i', [0]) * 3
@Serhiy Storchaka:
The keyword is "efficiently". Let's analyze: this creates useless
array.array('i', [0]) object destined only for garbage collection. Then, it
forces using loop of loops to fill in a new object. Whereas array.array('i', 3)
immediately reduces to a memset().
You can say that these implementation efficiency issues are of little concert
to CPython. But what's being reported here is that, while generally Python is
pretty good in allowing to efficiently process raw binary data (memoryview and
all other bits and pieces), there are inconsistent accidental gaps in API here
and there which jeopardize efficiency, in obvious way (and also obvious to
resolve), what may be of concern for other Python implementations (my case).
--
___
Python tracker
<http://bugs.python.org/issue21180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17345] Portable and extended type specifiers for array module
Paul Sokolovsky added the comment: See also http://bugs.python.org/issue9066 -- nosy: +pfalcon ___ Python tracker <http://bugs.python.org/issue17345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9066] Standard type codes for array.array, same as struct
Paul Sokolovsky added the comment: See also http://bugs.python.org/issue17345 -- ___ Python tracker <http://bugs.python.org/issue9066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9066] Standard type codes for array.array, same as struct
Paul Sokolovsky added the comment: > It's not clear to me that importing specifier prefixes from the struct module > is the best way to go about this, though. What are other alternatives then? Using struct's syntax has obvious benefit of being consistent and not confusing people any further. -- nosy: +pfalcon ___ Python tracker <http://bugs.python.org/issue9066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
New submission from Paul Sokolovsky:
With bytearray, you can do:
>>> bytearray(3)
bytearray(b'\x00\x00\x00')
However, with arrays:
>>> array.array('i', 3)
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int' object is not iterable
Given that int passed as seconf argument is not handled specially in array, I'd
like to propose to make it an initial size of a zero-filled array to create.
This will make it: a) consitent with bytearray; b) efficient for the scenarios
where one needs to pre-create array of given length, pass to some (native)
function to fill in, then do rest of processing. For the latter case, assuming
that both fill-in and further processing is efficient (e.g. done by native
function), the initial array creation becomes a bottleneck.
--
components: Library (Lib)
messages: 215757
nosy: pfalcon
priority: normal
severity: normal
status: open
title: Cannot efficiently create empty array.array of given size, inconsistency
with bytearray
type: performance
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue21180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17145] memoryview(array.array)
Changes by Paul Sokolovsky : -- nosy: +pfalcon ___ Python tracker <http://bugs.python.org/issue17145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3
Paul Sokolovsky added the comment:
Yes, and my note about "scientificity" above. Also compare with your own
account of time.perf_counter() above ("Usually time.perf_counter() is the
expected function.")
Also, I didn't want to start discussion on how to do benchmarking right, just
to point out a small inconsistency, and suggest a fix which balances on
(down-to-earth) correctness and practicality. It even can be ignored, except
that such small inconsistencies accumulate and then some time later stick from
every hole if not addressed.
--
___
Python tracker
<http://bugs.python.org/issue20475>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3
Paul Sokolovsky added the comment: > The problem with pystone is that such tool is used to compare performances > between different versions of Python. That's why I just propose to switch it to time.time(), which surely is available on each and every Python version and implementation. If there's a concern that some implementation may have only 1-second precision, then: 1) well, pystone has limits to its "scientificity", it's more like quick-run-anywhere, there's pybench for "real" testing (it's maintained and supported I hope); 2) number of iteratations can be bumped from 50K to 200K-500K. -- ___ Python tracker <http://bugs.python.org/issue20475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3
Changes by Paul Sokolovsky : -- components: +Benchmarks versions: +Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue20475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20475] pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3
New submission from Paul Sokolovsky: http://docs.python.org/3.3/library/time.html#time.clock says that it's deprecated, but pystone.py in Python-3.4.0b3 tarball still uses it. Please kindly consider switching it to plain time.time() and not to some other novelties. My usecase is: I'm working on alternative Python implementation, I of course want to benchmark it, and of course want to claim that I ran unmodified pystone.py. Now to achieve that, I need to implement deprecated function. -- messages: 209916 nosy: pfalcon priority: normal severity: normal status: open title: pystone.py in 3.4 still uses time.clock(), even though it's marked as deprecated since 3.3 type: enhancement ___ Python tracker <http://bugs.python.org/issue20475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346238] A constant folding optimization pass for the AST
Paul Sokolovsky added the comment: 8 years after the original patch, there's still no trivial constant folding in bytecode generated (because peephole of course is not a real optimizer to consistently catch all cases): $ cat const.py FOO = 1 BAR = FOO + 2 + 4 $ python --version Python 2.7.3 $ python -OO -m dis const.py 1 0 LOAD_CONST 0 (1) 3 STORE_NAME 0 (FOO) 2 6 LOAD_NAME0 (FOO) 9 LOAD_CONST 1 (2) 12 BINARY_ADD 13 LOAD_CONST 2 (4) 16 BINARY_ADD 17 STORE_NAME 1 (BAR) 20 LOAD_CONST 3 (None) 23 RETURN_VALUE $ python3.3 --version Python 3.3.3 $ python3.3 -OO -m dis const.py 1 0 LOAD_CONST 0 (1) 3 STORE_NAME 0 (FOO) 2 6 LOAD_NAME0 (FOO) 9 LOAD_CONST 1 (2) 12 BINARY_ADD 13 LOAD_CONST 2 (4) 16 BINARY_ADD 17 STORE_NAME 1 (BAR) 20 LOAD_CONST 3 (None) 23 RETURN_VALUE -- nosy: +pfalcon ___ Python tracker <http://bugs.python.org/issue1346238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10203] sqlite3.Row doesn't support sequence protocol
Changes by Paul Sokolovsky : -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue10203> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10203] sqlite3.Row doesn't support sequence protocol
New submission from Paul Sokolovsky :
sqlite.Row class doesn't implement sequence protocol, which is rather
unfortunate, because it is described and expected to work like a tuple, with
extra mapping-like functionality.
Specific issue I hit:
Adding rows to PyGTK ListStore,
model = gtk.ListStore(*db.getSchema())
for r in listGen():
model.append(r)
I get:
TypeError: expecting a sequence
Looking at PyGTK sources, append() method uses PySequence Check() on the
argument. Looking at Python 2.6.5 abstract.c:
int
PySequence_Check(PyObject *s)
{
if (s && PyInstance_Check(s))
return PyObject_HasAttrString(s, "__getitem__");
if (PyObject_IsInstance(s, (PyObject *)&PyDict_Type))
return 0;
return s != NULL && s->ob_type->tp_as_sequence &&
s->ob_type->tp_as_sequence->sq_item != NULL;
}
And sqlite3.Row doesn't set ob_type->tp_as_sequence as of Py 2.6.5 or 2.7.
--
components: Library (Lib)
messages: 119639
nosy: pfalcon
priority: normal
severity: normal
status: open
title: sqlite3.Row doesn't support sequence protocol
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue10203>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
