Glyph Lefkowitz added the comment:
My preference would be to fix it one way or another; the stdlib should be
correct before it's performant. If, as you say, it's better to write the
methods longhand anyway for ease of debugging, then it makes sense to write
them out for performance, too
Glyph Lefkowitz added the comment:
> We could do that and not incur performance issues. However, it would expand
> the API and double the size of the code.
If the preference is to not support this use-case, then I'd rather the
decorator simply raise an exception and tell me this is
Glyph Lefkowitz added the comment:
> Do you all have preference for 1) expanding the range of use cases to cover
> metaclasses but incurring a performance hit for common cases, or 2) leaving
> it as-is and documenting that it doesn't work for metaclasses?
If we do need the slow
Glyph Lefkowitz added the comment:
Adding versions after confirming the bug is the same on 3.10
--
versions: +Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44
New submission from Glyph Lefkowitz :
Consider the following example that attempts to make a series of types sortable
by their class name:
from functools import total_ordering
@total_ordering
class SortableMeta(type):
def __new__(cls, name, bases, ns):
return super().__new__
Glyph Lefkowitz added the comment:
For what it's worth, I've long since adapted to the status quo here, so I'm
happy for this to just be closed :-).
(Apple seems to have mostly given up on "domains" as a user-facing or even
developer-facing concept, so searching /Network
Glyph Lefkowitz added the comment:
The behavior is the same with a traditional quoted forward declaration, so it’s
not specific to the __future__ import; I just phrased the example that way to
show how it’s going to look in the future and to illustrate how it might crop
up in a way which
New submission from Glyph Lefkowitz :
This example:
from __future__ import annotations
from functools import singledispatchmethod
class Comparable:
@singledispatchmethod
def compare(self, arg: object):
raise NotImplementedError("what")
@compare.register
Glyph Lefkowitz added the comment:
I also just discovered this. I thought it must have regressed at some point
but I see the docs say "new in 3.8" and I'm using 3.8.
Is there a "no CI for examples in the docs" issue that this could be linked to?
---
Glyph Lefkowitz added the comment:
gwk, I absolutely agree; at this point that's the main thing I'm looking for.
But it would be great if whoever adds that documentation could include the
rationale for this behavior too. It still seems "obvious" to me that it should
change the
Glyph Lefkowitz added the comment:
This bug has been filed several times:
issue1257
issue11654
and it's tempting to simply close this as a dup, but this ticket mentions the
documentation, which is slightly confusing:
https://docs.python.org/3.8/library/atexit.html#atexit.register
It's
Glyph Lefkowitz added the comment:
I hope nobody will mind if I close: It's a duplicate of issue1257 so future
discussion, if any, should probably happen there.
--
nosy: +glyph
resolution: -> duplicate
stage: -> resolved
status: open -&g
Changes by Glyph Lefkowitz <gl...@twistedmatrix.com>:
--
status: open -> pending
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Glyph Lefkowitz <gl...@twistedmatrix.com>:
--
nosy: +glyph
status: pending -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Glyph Lefkowitz added the comment:
For what it's worth, it would still be great if this could be merged. It could
help a lot with 2/3 migrations of async code that uses Twisted and wants to
adopt some asyncio parts. Right now the stdlib SSL module is de-facto useless
in those scenarios
Glyph Lefkowitz added the comment:
I just bumped into this myself. If this really is only fixable in a major
release, there ought to at least be a minor release for the *documentation* to
update it to be correct.
--
nosy: +glyph
___
Python tracker
Glyph Lefkowitz added the comment:
OK, cool. So, long term, there will be a way to do this (suspend within a
generator expression). Thanks for the pointer.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Glyph Lefkowitz added the comment:
(As far as awaiting on int, yes, I know how await works, I was focusing on the
syntax.)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Glyph Lefkowitz added the comment:
>>> async def foo():
... bar = [await x for x in range(10)]
File "", line 2
SyntaxError: 'await' expressions in comprehensions are not supported
--
___
Python tracker <rep...@
Glyph Lefkowitz added the comment:
Is the fact that 'await' produces a syntax error in this context the same bug
or a new one?
--
nosy: +glyph
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Glyph Lefkowitz added the comment:
For what it's worth, I don't much care whether this is fixed or not; I ended up
wanting to leak less information from the RNG output anyway so I wrote this:
https://gist.github.com/glyph/ceca96100a3049fefea6f2035abbd9ea
but I felt like it should be reported
Glyph Lefkowitz added the comment:
Changing the affected version to just 2.7.
--
versions: -Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Glyph Lefkowitz added the comment:
It does seem to be stable on python 3, but on python 2.7 it's definitely a
problem:
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str,
(r.randrange(10) for x in range(10, hash('abc'))"
('9553343809', -197265983
New submission from Glyph Lefkowitz:
The purpose of 'seeding' a random number generator is usually to supply a
deterministic sequence of values starting from a known point. This works fine
if you seed random.Random with an integer. Often (for example, see Minecraft's
map generation
Glyph Lefkowitz added the comment:
XDG_CONFIG_HOME is not generally set to anything; the default of ~/.config is
usually fine. However, the point is that you _can_ set it to point at a
different location. The relevant specification is here:
http://standards.freedesktop.org/basedir-spec
Glyph Lefkowitz added the comment:
Would simply replacing this function with pipes.quote resolve the issue?
--
nosy: +glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22187
Changes by Glyph Lefkowitz gl...@twistedmatrix.com:
--
nosy: -glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21965
___
___
Python-bugs-list
Glyph Lefkowitz added the comment:
I don't have a whole lot to add. I strongly recommended that this be done this
way twice, once when ssl was added to Python and once when ssl was added to
tulip, so I'm glad to see it's happening now. Regarding the specific
implementation I am unlikely
Glyph Lefkowitz added the comment:
Just my 2¢ here: rather than debating cases in the abstract, it would be
interesting to 'pip install' a couple of popular 2.x-only packages and see if
the error message is an improvement.
My experience is that learners don't hit this so much by writing
Glyph Lefkowitz added the comment:
Tempting as it is to reply to the comment about 'buffer' not existing, we're
way off topic here. Let's please keep further comments on this bug to issues
about a 'format' methods on the 'bytes' object
Glyph Lefkowitz added the comment:
On Oct 8, 2013, at 8:10 AM, Augie Fackler rep...@bugs.python.org wrote:
Hah. Probably too slow for anything beyond a proof of concept, no?
It should perform acceptably on PyPy ;-).
--
___
Python tracker rep
Glyph Lefkowitz added the comment:
On Oct 8, 2013, at 2:35 PM, Eric V. Smith wrote:
What proposal is actually on the table here?
Sorry Eric, you're right, there is too much discussion here. This issue ought
to be about .format, like the title says. There should be a separate ticket
Glyph Lefkowitz added the comment:
On Oct 8, 2013, at 3:19 PM, Augie Fackler wrote:
No, I'm not. In Mercurial, all end-user data is OPAQUE BYTES, and must remain
that way.
The PEP 383 technique for handling file names is completely capable of
round-tripping exact bytes, given one encoding
Glyph Lefkowitz added the comment:
It would be nice for this to be fixed in a 2.7.x release too, if possible,
since the workaround involves a ton of extra system calls and there's no other
way to construct a socket object directly.
--
nosy: +glyph
versions: +Python 2.7
Glyph Lefkowitz added the comment:
Wouldn't it be better to check for the actual problem, that is use subprocess
to start a small Tcl script that creates a window and check if that crashes?
Yes, this sounds great. Doing it with Tcl means that we're not invoking any of
the problematic code
Glyph Lefkowitz added the comment:
Hi Ned,
It seems from your comment that you didn't read the patch. Alex added a
simpler check via launchctl, rather than by framework symbol groveling :). He
didn't remove the check.
It should be functionally identical to what's there now, but much
Glyph Lefkowitz added the comment:
Confirmed. Thanks very much for addressing it promptly.
--
resolution: - duplicate
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17298
New submission from Glyph Lefkowitz:
As reported in Twisted:
https://twistedmatrix.com/trac/ticket/6314
and as seen on the Twisted buildbot:
https://buildbot.twistedmatrix.com/builders/lucid32-py2.7maint/builds/2327/steps/trial/logs/problems
The tip of the 2.7 branch is now failing Twisted's
Glyph Lefkowitz added the comment:
Yes; perhaps that change should be rolled back until a fix for the regression
can be added?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17298
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:27 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
The ASCII superset commands part is clearly separated from the binary
data part. Your own LineReceiver is able to switch between raw mode
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:31 PM, Martin v. Löwis rep...@bugs.python.org wrote:
I admit that it is puzzling that string interpolation is apparently the
fastest way to assemble byte strings. It involves parsing the format string,
so it ought to be slower than
Glyph Lefkowitz added the comment:
On Jan 23, 2013, at 1:58 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Numbers currently don't have a __bytes__ method:
(5).__bytes__()
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'int' object has no attribute
Glyph Lefkowitz added the comment:
On Jan 23, 2013, at 11:02 AM, Antoine Pitrou rep...@bugs.python.org wrote:
I would agree with you, but it's probably too late to change...
Understandable, and, in any case, out of scope for this ticket
Changes by Glyph Lefkowitz gl...@twistedmatrix.com:
--
nosy: +glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12411
___
___
Python-bugs-list
Changes by Glyph Lefkowitz gl...@twistedmatrix.com:
--
nosy: +glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list
Changes by Glyph Lefkowitz gl...@twistedmatrix.com:
--
nosy: +glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15958
___
___
Python-bugs-list
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:39 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
I agree with the idea that the feature set should very limited, actually
perhaps more limited than what you just said. For example, I think any
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 1:46 PM, STINNER Victor rep...@bugs.python.org wrote:
2013/1/22 Guido van Rossum rep...@bugs.python.org:
Twisted still would like to see this.
Sorry, but this argument doesn't convince me. A better argument is
that bytes+bytes
Glyph Lefkowitz added the comment:
Antoine Pitrou added the comment:
The fact that there are plenty of other Python applications that don't
use Twisted which nevertheless need to emit formatted sequences of
bytes is *precisely* a good reason for this to be discussed more
visibly.
I don't
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 3:34 PM, Terry J. Reedy rep...@bugs.python.org wrote:
I presume this would mean adding 'if py3: out = out.encode()' after the
formatting. As I said before, this works much better in 3.3+ than in 3.2-.
Some actual numbers:
I'm glad
Glyph Lefkowitz added the comment:
It's worth noting that the buffer() built-in in Python2 had this behavior,
and it enabled a copy-reduction optimization within Twisted's outgoing
transport buffer.
There are of course other ways to do this, but it seems like it would be nice
to restore
Glyph Lefkowitz added the comment:
Le Oct 11, 2012 à 12:13 PM, Antoine Pitrou rep...@bugs.python.org a écrit :
Antoine Pitrou added the comment:
I'm not sure what you're talking about since:
b = buffer(abc)
b + xyz
'abcxyz'
(b + xyz) is b
False
... doesn't look like it avoid
Glyph Lefkowitz added the comment:
Yes, it would be *possible* to fix it with that alone, but that still makes it
a pointless 'gotcha' in differing behavior between memoryview and buffer,
especially given that bytes+memoryview does something semantically different
than memoryview+bytes
Glyph Lefkowitz gl...@twistedmatrix.com added the comment:
Charles-François:
Also, I must admit I'm quite skeptical about the real benefit of
explicit probes for user-land, especially for CPython which isn't used
for performance-critical systems...
I beg to differ. CPython is totally used
Glyph Lefkowitz gl...@twistedmatrix.com added the comment:
This has been a serious annoyance in the Twisted and pyOpenSSL release
processes; it effectively prevents us from timely uploads of win32 binaries of
any kind.
--
nosy: +glyph
___
Python
Glyph Lefkowitz gl...@twistedmatrix.com added the comment:
I would still prefer
~/.local/something-parallel-to-where-it's-usually-installed for its ease of
documentation. But ~/.python/X.Y isn't terribly objectionable.
A minor point about Michael Foord's fallback proposal: I don't know why
Glyph Lefkowitz gl...@twistedmatrix.com added the comment:
I agree with Michael Foord; my comment on issue 8404
http://bugs.python.org/issue8084#msg122935 may be of interest to anyone
looking at this as well.
--
___
Python tracker rep
Glyph Lefkowitz gl...@twistedmatrix.com added the comment:
Would it be possible to have this reverted for 2.7.2 / 3.2.1, and restore
~/.local _and_ ~/Library as equally valid locations for python code?
As I tried to explain on the mailing list, this change basically introduces a
regression
Glyph Lefkowitz gl...@twistedmatrix.com added the comment:
Well, that makes it the user-specific equivalent of /usr or /usr/local.
Do you put your configuration files in /usr/local ? Why put them
in .local ?
Yes, software built for /usr/local will often respect /usr/local/etc in
addition
Changes by Glyph Lefkowitz gl...@divmod.com:
--
nosy: +glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4111
___
___
Python-bugs-list mailing
Glyph Lefkowitz gl...@divmod.com added the comment:
It suggests to me that somewhere there's some documentation, or an
example, that says this is the right way to embed python, call this
function.
If the right thing to do is to just not call the function at all, we
need to get that knowledge
Glyph Lefkowitz gl...@divmod.com added the comment:
IOW, I *really* want to understand what's happening before fixing
it. This is a security issue, after all.
Agreed. Does anyone currently subscribed to this ticket know the author
of such an application? It would be very helpful to have
Glyph Lefkowitz gl...@divmod.com added the comment:
Antoine,
The problem is that apparently every program that embeds Python calls
PySys_SetArgv and does not understand the consequences of doing so. For
example, a user running 'gedit' to edit some files in a potentially
insecure directory may
Changes by Glyph Lefkowitz gl...@divmod.com:
--
nosy: +glyph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5753
___
___
Python-bugs-list mailing
New submission from Glyph Lefkowitz gl...@divmod.com:
c.f. this Twisted ticket: http://twistedmatrix.com/trac/ticket/3703
Twisted's test tool has an extended TestCase which uses the 'skip'
attribute, on both tests and methods, to determine whether to skip them.
You can see the implementation
Glyph Lefkowitz [EMAIL PROTECTED] added the comment:
Looks like we just misunderstood the way the warnings filter works, and
catch_warnings' interaction with it. Thanks for the priority bump,
guido, and sorry for the false alarm!
--
nosy: +glyph
status: open - closed
Changes by Glyph Lefkowitz [EMAIL PROTECTED]:
--
resolution: - invalid
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3780
___
___
Python-bugs-list
Glyph Lefkowitz [EMAIL PROTECTED] added the comment:
The use of the term filter is pretty confusing. I would normally say
it was just me, but a bunch of other Twisted hackers seemed to interpret
it the same way: a filter is something that has an opportunity to
remove something else
Glyph Lefkowitz [EMAIL PROTECTED] added the comment:
As barry said, this should have been a release blocker for the first
beta... ;-)
--
nosy: +glyph
priority: critical - release blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org
Glyph Lefkowitz [EMAIL PROTECTED] added the comment:
pitrou: You're missing a few steps. If you are maintaining project X,
which depends on library Y, that adds a showwarning hook for some
reason, you need to:
* check out a development version of library Y, which you do not
normally maintain
Glyph Lefkowitz [EMAIL PROTECTED] added the comment:
I don't understand your objection. It sounds like you're objecting, but
then suggesting an implementation? The line you suggest might just as
easily be present in py3k's default site.py and it would work fine.
As I understand it, sites
Glyph Lefkowitz [EMAIL PROTECTED] added the comment:
The idea is that PYTHON3PATH will be honored in preference to
PYTHONPATH, but PYTHONPATH will still be honored. It's exposed only to
people who specifically need it.
However, I think it's misleading to call the Python 3 transition
New submission from Glyph Lefkowitz [EMAIL PROTECTED]:
Currently if you have both Python 3 and Python 2 installed, there's no
way to indicate that .py files in one area are Python 2 syntax and in
another area are Python 3 syntax. Being able to distinguish between
these would be nice
73 matches
Mail list logo