Lysandros Nikolaou added the comment:
Is this expected behaviour, should the tests be changes, or is it a bug?
--
___
Python tracker
<https://bugs.python.org/issue34
New submission from Lysandros Nikolaou :
In the Doc README there is the following sentence after the make venv command:
Assuming the virtual environment was created in the env directory (the default;
configurable with the VENVDIR variable)
Should't it be venv directory instead
Change by Lysandros Nikolaou :
--
title: Doc README wrong directory name for vent -> Doc README wrong directory
name for venv
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
When running the terminal command host '0.1.1.~1' I get the following output:
0.1.1.~1 has address 62.138.239.45
0.1.1.~1 has address 62.138.238.45
Host 0.1.1.~1 not found: 3(NXDOMAIN)
Host 0.1.1.~1 not found: 3(NXDOMAIN)
If I ping the above IP address
New submission from Lysandros Nikolaou :
On my Mac OS X 10.13.6 system test_socket.test_host_resolution_bad_address
fails with the following error:
==
FAIL: test_host_resolution_bad_address
Lysandros Nikolaou added the comment:
Upon checking to see where the RuntimeError is coming from, I noticed that
there is some notorious behaviour in chunk.py. If one runs python with the
exact same parameters as Jussi Judin did in their first case and after stepping
through the call stack
Lysandros Nikolaou added the comment:
Will you make a PR or shall I try to fix this?
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue34
Lysandros Nikolaou added the comment:
I would be happy to change this. I will submit a PR ASAP.
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue34
Lysandros Nikolaou added the comment:
Also this throws a TypeError, because http_info.get_content_charset() returns
None with the new link. I think, this should be fixed as well.
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.
Lysandros Nikolaou added the comment:
IMHO this is not a bug. Every file starting with a dot is hidden by default, so
this is somewhat correct behaviour. Since it is documented correctly I don't
this something needs to change here.
Yet again, could someone more experienced offer
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +9521
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32804>
___
_
Lysandros Nikolaou added the comment:
Shall I create a PR for this?
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue30410>
___
___
Pytho
New submission from Lysandros Nikolaou :
In sysconfig.py there is a comment starting with FIXME that states that
_PY_VERSION should get its value from sys.version_info instead of sys.version,
because it is an implementation detail.
Should this be changed? If so, I would like to create a PR
Lysandros Nikolaou added the comment:
I am trying to create a PR for this and was thinking of somehow updating
test.support, in order for someone to be able to find out what compiler was
used to build python. Would that make sense?
Also, in case this is indeed something we'd like
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +9575
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue30410>
___
_
Lysandros Nikolaou added the comment:
I'm working on changing _PY_VERSION to get its value from sys.version_info
instead of sys.version, but I am not sure what the best way is to map between a
release stage to the corresponding letter(release->rc). Could someone help me a
tiny
Change by Lysandros Nikolaou :
--
pull_requests: +9623
___
Python tracker
<https://bugs.python.org/issue24916>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +9619
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +9668
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue22021>
___
___
Py
Lysandros Nikolaou added the comment:
It's been more than 3 years, since this was opened, but I will ask
nevertheless. Should a PR maybe made for this issue?
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue25
Lysandros Nikolaou added the comment:
I think this issue should be discussed once more. I am not sure it's worth
defining __all__, but then we would have to include them in the docs. If you
think __all__ should be defined instead, then I could go through the trouble of
doing so. Could
Lysandros Nikolaou added the comment:
...but then we would have to include them in the docs... should be *but then we
would have to include all the public functions in the docs*.
--
___
Python tracker
<https://bugs.python.org/issue17
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue30533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
Is anybody working on this or can I submit a PR?
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue22
New submission from Lysandros Nikolaou :
On
https://docs.python.org/3/library/urllib.request.html?highlight=request#ftphandler-objects
there is the sentence "The login is always done with empty username and
password.", but in the (not so rare) case I am not missing something here,
New submission from Lysandros Nikolaou :
In test_functools.TestSingleDispatch.test_invalid_registrations
(https://github.com/python/cpython/blob/4c596d54aa6a55e9d2a3db78891e656ebbfb63c8/Lib/test/test_functools.py#L2299)
there is a FIXME with an immediate return afterwards that says
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +9797
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35252>
___
_
Lysandros Nikolaou added the comment:
It actually seems like the test after the FIXME is wrong and should be changed
or deleted altogether. Can someone give a pointer or two on what would be the
best choice here?
--
___
Python tracker
<ht
Lysandros Nikolaou added the comment:
Since Serhiy said that this is a pure documentation issue, I thought that a doc
PR is all that was needed, which I would be happy to make. Am I missing
something here?
--
___
Python tracker
<ht
Lysandros Nikolaou added the comment:
Following up on
https://github.com/python/cpython/pull/10321#discussion_r230604393 I would like
to summarise here what's been going on, in order to move the discussion here
forward. I've tried to make a PR for this issue, in which _PY_VERSION in
Lib
Lysandros Nikolaou added the comment:
Can I submit a PR for this or is anybody else on it?
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue34
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue35398>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
I updated the PR with the new wording by Paul, since I found it easier to
understand as well.
--
___
Python tracker
<https://bugs.python.org/issue30
Lysandros Nikolaou added the comment:
Ping.
--
___
Python tracker
<https://bugs.python.org/issue22021>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
Ping.
--
___
Python tracker
<https://bugs.python.org/issue30410>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +9891
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
keywords: +patch, patch, patch
pull_requests: +9891, 9892, 9893
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
keywords: +patch, patch
pull_requests: +9891, 9892
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
Yeah, I am not currently working on this, so feel free to make a PR anytime you
want.
--
___
Python tracker
<https://bugs.python.org/issue35
Lysandros Nikolaou added the comment:
Noah, are you working on this?
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue21314>
___
___
Pytho
Lysandros Nikolaou added the comment:
This issue still stands. The output of all three methods is exactly the same as
it was when the original question was posted. Would it maybe make sense to add
a flag to the unquote_to_bytes method to parse the 'plus' symbol as a space? Or
maybe create
Lysandros Nikolaou added the comment:
Ping for review.
--
___
Python tracker
<https://bugs.python.org/issue21314>
___
___
Python-bugs-list mailing list
Unsub
Lysandros Nikolaou added the comment:
Pinging once more for review.
--
___
Python tracker
<https://bugs.python.org/issue22021>
___
___
Python-bugs-list mailin
Lysandros Nikolaou added the comment:
Not that it makes a big difference, but write_text is a method of the Path
class, not PurePath.
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue36
Lysandros Nikolaou added the comment:
For reference,
https://docs.python.org/3/library/pathlib.html#pathlib.Path.write_bytes.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +12159
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36182>
___
_
Lysandros Nikolaou added the comment:
I'll submit a PR shortly.
--
___
Python tracker
<https://bugs.python.org/issue36182>
___
___
Python-bugs-list mailin
New submission from Lysandros Nikolaou :
Hi,
in the pathlib.Path.write_bytes() documentation it is clearly stated that "An
existing file of the same name is overwritten." Wouldn't it make sense to
include something similar to the pathlib.Path.write_text() docs. I had to
qu
Lysandros Nikolaou added the comment:
Can confirm for 3.7.2 on my macOS 10.14 system. Although this is the case in
3.7 on my current build of the master branch I get the following AssertionError
instead:
Assertion failed: (v->ob_type == w->ob_type), function unsafe_tuple_compare,
Lysandros Nikolaou added the comment:
I agree with Nick, that pydoc should somehow be updated to mark positional-only
parameters as such. I believe that the third approach proposed by Nick is the
most sensible one, as it makes the life of new developers easier by explicitly
listing all
Lysandros Nikolaou added the comment:
This can be most likely be closed. In the last days I had some unrelated
problems with my mac and had to do a full format. After reinstalling macOS the
problem went away, so it must have been something specific to my previous state
of things
New submission from Lysandros Nikolaou :
Since recently, Homebrew refuses to link sqlite. Upon researching the whole
thing, I found out that this is now considered a feature of Homebrew and not a
bug. Thus homebrew users on macOS do not get the SQLite module installed by
default, because
Lysandros Nikolaou added the comment:
@brettcannon, yeah I saw that, but there hasn't been any progress since
November. I'm still interested in this though. What would the correct workflow
be? Pushing commits to the same PR or opening a new one with a co-author
Lysandros Nikolaou added the comment:
Is anybody still working on this?
--
___
Python tracker
<https://bugs.python.org/issue35328>
___
___
Python-bugs-list m
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue35328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
resolution: -> duplicate
___
Python tracker
<https://bugs.python.org/issue36966>
___
___
Python-bugs-list mailing list
Un
Lysandros Nikolaou added the comment:
It is. Somehow search failed me big time. I'm closing the issue.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
New submission from Lysandros Nikolaou :
For those, who use custom tools for their terminals, prepending __VENV_PROMPT__
to PS1 doesn't really help all that much, because it gets overwritten by those
tools. Would it make sense to export __VENV_PROMPT__ as an environment variable
upon
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
Mariatta noted at
https://mail.python.org/archives/list/core-mentors...@python.org/message/KFIGNAGJKWQXCXG72VGIGGA3OCKUHOFC/
that these issues are not reserved and are now available for first-time
contributors.
--
nosy: +lys.nikolaou
Lysandros Nikolaou added the comment:
Mariatta noted at
https://mail.python.org/archives/list/core-mentors...@python.org/message/KFIGNAGJKWQXCXG72VGIGGA3OCKUHOFC/
that these issues are not reserved and are now available for first-time
contributors.
--
nosy: +lys.nikolaou
Lysandros Nikolaou added the comment:
Pinging for review.
--
___
Python tracker
<https://bugs.python.org/issue36182>
___
___
Python-bugs-list mailing list
Unsub
Lysandros Nikolaou added the comment:
There was a bug in my last PR, hopefully I will get a fix some time later today.
The bug is as follows: I only updated the asdl_seq_SET call for an elif without
an else, if an else is included then the behavior is like before.
After my last PR it looks
Change by Lysandros Nikolaou :
--
pull_requests: +17068
pull_request: https://github.com/python/cpython/pull/17596
___
Python tracker
<https://bugs.python.org/issue39
New submission from Lysandros Nikolaou :
When a starred expression like *[0, 1] is parsed, the following AST gets
generated:
Module(
body=[
Expr(
value=Starred(
value=List(
elts=[
Constant
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +17113
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17645
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
title: Inconsistent lineno and col_offset info when parsing elif ->
Inconsistency with lineno and col_offset info when parsing elif
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
While working on pegen, we came across an inconsistency on how line number and
column offset info is stored for (el)if nodes. When parsing a very simple
if-elif construct like
if a:
pass
elif b:
pass
the following parse tree gets generated
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +17056
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17582
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +17059
pull_request: https://github.com/python/cpython/pull/17585
___
Python tracker
<https://bugs.python.org/issue39
Lysandros Nikolaou added the comment:
Are you going to work on a patch then, Batuhan?
--
___
Python tracker
<https://bugs.python.org/issue39474>
___
___
Pytho
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue39474>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
title: Parsed expression has wrong line/col info when concatenating f-strings
-> Parsed expression has wrong col_offset when concatenating f-strings
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
When concatenating f-strings, if there is an expression in any STRING node
other than the first, col_offset of the parsed expression has a wrong value.
For example, parsing f"hello" f"{world}" outputs the following AST:
Module(
Lysandros Nikolaou added the comment:
Also note that for pegen this is a solved problem. If we decide to change the
parser, it may not be worth it to spend too much time on a universal solution.
--
___
Python tracker
<https://bugs.python.
Lysandros Nikolaou added the comment:
> Can I ask how pegen solved this problem? Did you move parsing of f-strings
> into the grammar?
No, we actually do a very similar thing to what ast.c does.
I think there is only one major difference between what pegen does and what
ast.c does
New submission from Lysandros Nikolaou :
There is a problem with the end_col_offset of nested Attribute nodes in
decorators. For example, parsing
@a.b.c
def f(): pass
produces the following AST tree (part):
decorator_list=[
Attribute(
value=Attribute(
value=Name
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +17781
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18405
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +17783
pull_request: https://github.com/python/cpython/pull/18408
___
Python tracker
<https://bugs.python.org/issue39
New submission from Lysandros Nikolaou :
At the moment running python -m venv venv or python3 -m venv venv creates a
virtual environment that does not contain a python. symlink,
which results in executing whatever the default python is when running i.e.
python. within an activated virtual
Lysandros Nikolaou added the comment:
The thing is that some projects I've worked on, like pegen, include a Makefile
which uses `pythonX.Y` to choose the version and I have to change it to
`python` quite frequently.
I can't really figure out any way this could harm anyone, other than what
Lysandros Nikolaou added the comment:
You're right! That could be very confusing. But isn't this risk already there,
since this could happen if one runs `python3.8 -m venv venv` and then
`python3.7` with the venv activated?
--
___
Python tracker
Lysandros Nikolaou added the comment:
That's right. I'll do that then. Thanks for baring with me.
Should we update the docs to mentiom this or just close this issue?
On Sat, Feb 15, 2020, 22:33 Vinay Sajip wrote:
>
> Vinay Sajip added the comment:
>
> In general, people shoul
Change by Lysandros Nikolaou :
--
pull_requests: +17320
pull_request: https://github.com/python/cpython/pull/17582
___
Python tracker
<https://bugs.python.org/issue16
New submission from Lysandros Nikolaou :
A normal generator expression like (i for i in a) produces the following AST:
Module(
body=[
Expr(
value=GeneratorExp(
elt=Name(
id="i", ctx=Load(), lineno=1, col_offset=1, en
Lysandros Nikolaou added the comment:
Do you think it is okay to just remove the call to copy_location?
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +18871
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19521
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
In my understanding of the C code that's what the C tokenizer is doing as well.
Here's the relevant snippet of the tokenizer
(https://github.com/python/cpython/blob/4b222c9491d1700e9bdd98e6889b8d0ea1c7321e/Parser/tokenizer.c#L1358):
When the tokenizer
Lysandros Nikolaou added the comment:
I have working code that checks if there is a quotation mark right after an
identifier. Here is an example:
╰─ ./python
Python 3.9.0a5+ (heads/pegen-dirty:502dfb719e, Apr 11 2020, 14:43:12)
[GCC 9.2.1 20191008] on linux
Type "help", "copyr
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +18830
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19476
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue40334>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Lysandros Nikolaou :
While testing pegen, we found this out:
Python 3.9.0a5+ (heads/pegen:502dfb719e, Apr 10 2020, 20:57:05)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more informat
Change by Lysandros Nikolaou :
--
nosy: +gvanrossum, pablogsal
___
Python tracker
<https://bugs.python.org/issue40246>
___
___
Python-bugs-list mailing list
Unsub
Lysandros Nikolaou added the comment:
It seems that this is actually a bit bigger than this and it is not specific to
f-strings.
The error message *always* changes to `unexpected EOF while parsing` if there
is an error with the last character of the input and no newline follows
New submission from Lysandros Nikolaou :
There are cases, where the error message differs, when an expression is being
parsed inside an fstring. For example:
>>> f'{x+}'
File "", line 1
(x+)
^
SyntaxError: unexpected EOF while parsing
>>> (
Lysandros Nikolaou added the comment:
After some investigating, I found out that this is happening because when we
execute `fur''` in the interactive interpreter there is an implicit newline,
which means that EOF does not get reached.
OTOH there is no newline when passing it as a string
Change by Lysandros Nikolaou :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue40267>
___
___
Python-bugs-list mailing list
Unsubscrib
Lysandros Nikolaou added the comment:
At the moment, if the prefix is invalid, it gets tokenized as a NAME node and
the string following is tokenized as a STRING node with no prefix.
╰─ echo "ur''" | ./python -m tokenize
1,0-1,2:NAME 'ur'
Change by Lysandros Nikolaou :
--
pull_requests: +19091
pull_request: https://github.com/python/cpython/pull/19771
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19094
pull_request: https://github.com/python/cpython/pull/19774
___
Python tracker
<https://bugs.python.org/issue40
1 - 100 of 352 matches
Mail list logo
