> Skip, I think you have misunderstood the point I was making. It was
> not whether the loop variable should leak out of a list comprehension.
> Rather, it was whether a local variable should, so to speak, "leak into"
> a list comprehension. And the answer is: it depen
a one-liner
> change to gain some performance in a bugfix release.
One can read anything he wants into the Zen. I could respond with this
retort: "Although practicality beats purity," but I won't. :-)
Skip
___
Python-Dev mailing lis
On Mon, Jun 1, 2015 at 1:35 PM, Ned Deily wrote:
> I thought I was volunteering to get a pony. I was misinformed.
Ned,
Not to worry. I'm sure that by the time 3.6a0 is due, the PSF will be able
to scrape together the funds for a pony, perhaps even one with super powers:
ely identical to the parent process*.
All resources of the parent are inherited by the child process. *Note that
safely forking a multithreaded process is problematic*.
So, even if you get past this particular problem, the conventional wisdom
is, "don't do that."
Skip
n turn
red. Might a segfault provide enough output to debug?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
It's a known issue -- which I thought was fixed recently. I would have
responded sooner, but I couldn't remember where website bugs are to be
reported and figured someone would chime in with the link. I *don't*
think it's bugs.python.org, though I c
l there. In my environment, I interface with a lot of
Boost.Python-wrapped code which would be quite impractical to compile with
--with-pydebug. I'd like to be able to throw in all the other development
bells and whistles though, without changing the size of the object header.
Maybe "develop-
y'all will be busy trying to fix
these various problems as they relate to Python, but might it not be
better to simply tell people to hold off on the Python installers
until Apple gets their act together? Otherwise, I fear you'll just be
trying to hit a moving tar
, y'rs,
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
fferent about your underlying bug
than a value of 2013. Just knowing it's out of range isn't really
enough.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.py
> We could always run random.shuffle() on the current list
> so new additions don't look out of place ;)
Wouldn't that bloat the repository with diffs and make merges more difficult?
Skip
___
Python-Dev mailing list
Python-Dev@
n the
> "conversion derby" because of that.
My first thought was that this exercise falls into the realm of fixing
things which aren't broken.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mail
On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw wrote:
> I think we should be willing to entertain breaking feature freeze for getting
> this in Python 3.4.
Maybe you could revert 3.4 to alpha status and give it a cycle or two
there to get this done before returning to beta status.
, and possibly under what
conditions they might not? It might still be necessary to maintain
macros for those platforms.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.p
On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:
> Well, if we must maintain macros, let's maintain them everywhere and
> avoid the burden of two different implementations for the same thing.
Would it be possible to generate the macro versions from the
inline/static versions where necessary
k is still going to have to be done, no matter what
you call it. Why not be transparent about it?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
o what's the big deal? Why can't we be pragmatic and call this thing
(whatever it turns out to be) 2.8? Is this pledge and its rationale
written down in a PEP somewhere, so I can study the reasons behind
what appears at this point to be blind adherence? Did someo
on developers will have to make some changes to take
advantage of these updated security bits. Is there some path forward
that really makes everything a drop-in improvement, requiring no
change to application code, and breaking nothing that already works?
Skip
___
ths this duration refers to?
Timedelta objects are very precise beasts, which is almost certainly
why they don't support "years" and "months" args in their
constructors.
This is why I said this deserved a separate topic. Probably on python-ideas.
Skip
___
he sees fit. That would support
the ISO 8601 syntax (*), and anything else the programmer things is
better than the status quo.
Skip
(*) As an aside (that is, this belongs in a separate thread if you
want to discuss it), in my opinion, attempting to support ISO 8601
formatting is pointless without th
her. Is there a way to talk in terms of
"months" but not have short months get skipped?
Thx,
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
(well, actually, a Phython3)
directory.
WTH is Python 4?
Skip
-- Forwarded message --
From: C. Reese
Date: Thu, Apr 3, 2014 at 8:03 AM
Subject: Updated phython
To: webmas...@python.org
just updated to Python 4. (installed to C: drive) ... now i notice
there are separate Python2 &
ied that an
April Fool's prank went so far as to put a tarted up version of Python
3.x out in the wild where unsuspecting folks would find and install
it.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
7;import tradelink.snake.v11_2 ; raise SystemExit'
real 0m0.671s
user 0m0.405s
sys 0m0.044s
% time python -c 'raise SystemExit'
real 0m0.022s
user 0m0.011s
sys 0m0.009s
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
to lower the barrier enough for the
Mercurial folks, if, in fact, import slowness is their main reason for
not moving to 3.x.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
; reduction of penalty) will be noticeable.
Based on what I saw, I really don't think that startup slowness is in
imports of Python stdlib modules, which is all Brett was aiming at. I
*can* believe overall import slowness might be a problem, but in that
case, Brett's work isn't going to
ypically between 100ms and 400ms.
<http://en.wikipedia.org/wiki/Blink> If you blink, you've missed
Python 2.7 startup on a relatively modern machine.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinf
ust let that sleeping dog lie. I have
better things to do with my life. New stuff I write tends to be much
more pep8-ish.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
e that the brain has to do more work to read
> mixedCase names.
Given Guido's background, I suspect these studies might have been done
at CWI in the context of the ABC language.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https:/
one available?
Zach,
That's as a good a link as I know of. (Lot of water under the bridge
since then!)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
I wonder if one or more people who maintain unofficial forks on
minority platforms (OS/2, VMS, etc) could create an informational PEP
about the process (benefits and pitfalls) of that kind of effort?
Skip
___
Python-Dev mailing list
Python-Dev
p" place
for this. If failing, such buildbots wouldn't block a release, but
would still provide tools for people to track down the source of
breakage.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
On Thu, May 15, 2014 at 9:35 AM, Brett Cannon wrote:
> I view stable buildbots as staying up and testing critical platforms.
Would "supported" and "unsupported" (or "critical" and "optional"?)
make more sense? "Unstable" suggests "broken" to me, not "we don't
really care about these."
S
om "unstable" (or to view
just the "unstable" category. What do those two categories have to do
with "supported" and "unsupported"?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
e
lack of execfile is such a big deal for you, you might want to check around
to see how other people use interactive mode.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://m
bout the list's demise, then auto-forward their message to
python-list?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> I uploaded a tarfile I had on my PC to my web site:
>
> http://python.ca/nas/python/rattlesnake20010813/
>
> It seems his name doesn't appear in the readme or source but I think
> Rattlesnake was Skip Montanaro's project. I suppose my idea of
> unifying the lo
project. I
don't rightly recall if Roundup was deemed easier to modify or if
there were just people willing to step up and make the necessary
changes.
* There was a desire to eat your own dog food, and I believe Roundup
is/was written in Python. That would be much less important today.
Plenty
> My only complaint is that you steadfastly refuse use Guido’s time machine
> keys to make this available in 3.7.
Wait a minute, Barry. You mean you don't already have an Emacs
function to do the rewriting as a pre-save-hook?
Skip
___
ould be reasonable
to toss all these modules into GitHub or PyPI. Someone will want them.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
se who are using older
> technology. If not exclude them altogether.
Is that Git or GitHub? If the latter, more JavaScript bits or something else?
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-d
My only comment is that this belongs first on python-ideas
<https://mail.python.org/mailman3/lists/python-ideas.python.org/>.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
action=search&@filter=&@pagesize=50
This issue has the "easy" keyword:
https://bugs.python.org/issue19217
Are "newcomer friendly" and "easy" aimed at somewhat different targets?
Skip
Skip
___
Python
mit and am applying them oldest to
newest (against 3.3, which I think was Victor's base), correcting
issues as I go along. Still, that is going to take a good long while.
If there's an easier way to do this, I'm all ears.
Skip
___
Python-Dev m
r.txt
Thanks, Neil. I barely remembered anything about Mercurial (not even
installed on my current device). It didn't occur to me that the
necessary precursor to that big diff might be as simple as
hg clone https://hg.python.org/sandbox/registervm/
Skip
___
On Thu, Oct 29, 2020, 6:32 PM Gregory P. Smith wrote:
> I agree, remove Solaris support. Nobody willing to contribute seems
> interested.
>
*sniff* I spent a lot of professional time in front of SunOS and Solaris
screens. But yes, I agree. It seems time to give Solaris the bo
n manually work my way through it, but it sorta
seems like someone might have used a script to translate the output of
dis.dis(jumpy) into this list. Am I mistaken about this?
Thx,
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscri
> Maybe these lines in test_dis.py?
> ```
> #print('expected_opinfo_jumpy = [\n ',
> #',\n '.join(map(str, _instructions)), ',\n]', sep='')
> ```
Thanks, I'll take a look. I was expecting there'd be a standalone
script somew
Guido> Maybe these lines in test_dis.py?
...
Skip> Thanks, I'll take a look. I was expecting there'd be a standalone
Skip> script somewhere. Hadn't considered that comments would be hiding
Skip> code.
Indeed, that did the trick, however... I'm a bit uncomfortabl
s
module functionality (I'm guessing >= 50%), perhaps moving them to
test_compiler.py or something similar would be a stronger signal about
their intent.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email t
h the original files, a small
README file and a compile.patch file between the original code and the
runnable code.
It was a pleasant diversion for a couple hours. I was tired of shovelling
snow anyway... Thank you, Hiromi.
Skip
* Hiromi is bcc'd on this note in case he cares to comment.
>
> Wow. Was white-space not significant in this release of Python? I see the
>> lack of indentation in the first Python programs.
>>
>
> Indentation most certainly was significant from day 0. I suspect what
> happened is that these files got busted somehow by the extrac
nto correct format.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list
2, 2, 2, 2, 2, 2, 2, 2]
The tests don't pass though. 1 * 1 raises an integer overflow exception:
>>> 1 * 1
Unhandled exception: run-time error: integer overflow
Stack backtrace (innermost last):
File "", line 1
I'll let someone figure that out. :-)
At any rate,
n't planning to rebuild the documentation, I
didn't worry too much about that. I expected to need a bunch of manual
patchwork to get back to something that would even compile.
It's nice to know that in this case, "the Internet never forgets."
Skip
___
> If we can get a clean copy of the original sources I think we should put them
> up under the Python org on GitHub for posterity.
Did that earlier today:
https://github.com/python/pythondotorg/issues/1734
Skip
___
Python-Dev mailing list --
nce it compiled out of the box, and didn't dig into it when I saw the
error. Looking now, I see a 32-bit assumption:
if (x > 0x7fff || x < (double) (long) 0x8000)
return err_ovf();
With the -m32 flag, running lib/testall.py runs to completion.
Skip
_
my code I'm using
dis.findlinestarts() to determine the line numbers for each block. Perhaps
I should be modifying its results. OTOH, maybe it's a bug. (If that's the
consensus, I will create an issue.)
Skip
___
Python-Dev mailing list --
> co_lnotab has had negative deltas since 3.6.
Thanks. I'm probably misreading Objects/lnotab_notes.txt.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.py
s in PEP 0. I'm sure this is a
trivial few git commands for those more familiar with the toolchain than I
am, but I see over 18k forks of the repository. I suspect a few people out
of that crowd will be in the same boat as me.
Thx,
Skip
___
Python-D
which documents the various
arguments pro and con to short-circuit or inform future discussions. I'm
not volunteering to write it. Denis, maybe you could make a run at it.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
;duck typing" than always guarding accesses? I assume that
will still have a place in the pantheon of Python type variants.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://m
--help' for details.
I looked at the fast-forward stuff in 'git push --help' but couldn't
decipher what it told me, or more importantly, how it related to my
problem. It's not clear to me how python/cpython:main can be behind
smontanaro/cpython:main. I've attached my
ain
Then I went to Github and compared my fork with python/cpython:
https://github.com/python/cpython/compare/main...smontanaro:main
It appears I might have screwed the pooch by accepting Github's recent pull
request. I'm just a gitiot. How am I supposed to know not to accept the
hose merges are. Is that first commit
(Github (un)Dependabot) the culprit, or are all the other git merge
results also problematic?
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pytho
lit I was tracking main from a development
branch in my fork, and trying — lately pretty much unsuccessfully — to
drink from the firehose of changes to the virtual machine code. It
made sense to me to keep my fork's main up-to-date with upstream/main.
Now that I have diverged to follow the 3.10 branch
-Wno-unused-parameter
-Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -fvisibility=hidden
-I./Include/internal -I. -I./Include-DPy_BUILD_CORE -o Python/ceval.o
Python/ceval.c
I don't know if this is a GCC problem, a GDB problem, or a Skip problem. Is
th
I can move the actual point where GDB breaks by replacing -Og with -O0, but
it still breaks at the wrong place, just a different wrong place. If I set
a breakpoint by line number, it stops at the proper place.
Skip
___
Python-Dev mailing list -- python-de
s radar screen. In the meantime, to
get going again I wrote a crude script which maps the
file:function:label form to file:linenumber form. That way I can
save/restore breakpoints across GDB sessions and still avoid problems
when the offsets to specific i
r file,
Python/ceval_reg.h, which is #included in ceval.c at the desired spot.
Maybe that factors into the issue.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org
like a piece of cake). Still, the difference between
the announced and actual line numbers of the breakpoint remains.
I disabled Python support in GDB by renaming my ~/.gdbinit file which
declares
add-auto-load-safe-path /home/skip/src/python/rvm
That had no effect either. I don't have an
ifference between the two is the user interface it seems likely the bug
might surface there as well.
The use of a VM thus provides another option as a workaround for me, though
my simple-minded label-to-line number script works as well.
Skip
>
___
Py
low enterprising folks to
easily fork and reference back to the last point where the PEP 8 text did
mention Python 2.x.
(This no longer applies to me personally, as I have fully gone over to
Python 3, but at my last job there was still plenty of Python 2 code to be
had.)
Just a thought...
Skip
___
not an NNTP person (anymore), filters in Gmail (and I assume
other mail readers/apps) allow you to sequester mails into separate folders
which you can ignore if you like.
Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
ny, recursion, and result in a size increase of less than
a factor of 10 when fully expanded.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
an seems to have a use case, even if it is using enums to
masquerade as true named constants. Perhaps the correct solution is
to consider support for true constants in Python. (I would be
surprised if there wasn't already at least one rejected or dormant PEP
regarding that topic.)
Skip
___
>>> 1 < None
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: int() < NoneType()
>>>
It's not clear to me that sneaking artificial ordering in the back
door via enumerations is the correct thing to do.
Skip
at PSF World Headquarters to execute the electronic contributor
agreement? While not strictly necessary, I suspect it might be nice for
you to have all agreements in a common form.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
nk this belongs on python-ideas before launching into discussions
of syntax and semantics on python-dev.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
I started writing this last night before the flurry of messages which
arrived overnight. I thought originally, "Oh, Skip, you're being too
harsh." But now I'm not so sure. I think you are approaching the
issue of 2.7's EOL incorrectly. Of those discussing the end of Py
Obviously SourceForge doesn't think the current release interval is short
enough. (Emphasis mine.)
:-)
Skip
-- Forwarded message --
From: SourceForge.net
Date: Mon, Apr 8, 2013 at 1:09 PM
Subject: SourceForge Project Upgrade Notification
To: nore...@in.sf.net
ing to Python 3 wasn't going to be much more difficult, I
think we would have attempted that. 2.7 Seemed like the better step
though, especially considering its compatibility with 2.4 and the fact
that it has a lot of things backported from Python 3 to ease the
ev
h code bases altogether and
insert them where appropriate as part of the build process? That
said, I haven't any idea how you might accomplish that. Maybe this
general problem should be thrown over the python-ideas to cook for
awhile...
Skip
___
Python
> Some pieces of code are still guarded by:
> #ifdef HAVE_FSTAT
> ...
> #endif
Are there other guards for similarly common libc functions? If so,
perhaps each one should be removed in a series of change sets, one per
guard.
Skip
__
to debug about keyword
arguments if they are held in a normal dictionary? Debugging at the
Python level or the C level? Can you give an example where it would be
easier to debug? If it makes it easier here, would it make it easier
to debug other dictionary usage if they were ordered?
Skip
___
on (not sure it
even is today)
* Sometimes Cerberus was sleeping, and they snuck past him
In any case, once a module makes it into the standard library, the
cost of changing spelling outweighs the benefits of slavish adherence
to PEP 8.
Skip
___
Pytho
ttempt any debugging gymnastics (ow! my back
hurts) I thought I would check to see if Python makes much use of
double linked lists in a non-debug build. I don't recall a lot from
days of yore, perhaps some in the dict implementation?
Thanks,
Skip
___
pper.c:58)
==21374==by 0x40168D: main (binary-wrapper-main.c:382)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
, I go whole hog and don't
bother with the blank line either. (If I'm going to punch a hole in a
rule, I might as well create one big enough to comfortably walk
through.)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
the limit, so by eliminating
them, the shorter lines stand out more clearly.
Skip
<>___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
k up from
change 13 without having to start over, re-analyzing changes 1 through
12.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
tly not at your sprint).
:-)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
anation? I much prefer using OpenID to login to a
site than having to either come up with yet another username/password
which I will just forget, or using Facebook or similar (I don't really
trust them with my info).
Thx,
Skip
___
Python-Dev
farther without that. :-/
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
l sorts
of personal information to use their site.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e
DTrace folks at Apple and Sun weren't really interested in holding hands...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
27;t think gets a lot of use (or love). Might it be
worthwhile to make sure the
PEP 450 package works with that? Then extend it to multiple dimensions? Or just
bite the bullet and get numpy's array type into the Python core once
and for all?
Sort of Tulip for arrays...
Skip
__
he
collections module (I'm skeptical), shouldn't that behavior be more
strongly hinted at in the name? Lot's of things are transformations.
You're interested in a very specific one.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https:/
y
mind. A quick scan of your links suggests most people think something
like "cidict" or "CaseInsensitiveDict" would be more descriptive.)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
otes modules or packages
within other packages which haven't been imported yet). I never
realized that module used it.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
1001 - 1100 of 1295 matches
Mail list logo
