On December 16, 2015 8:12:47 AM CST, Serhiy Storchaka
wrote:
>I'm bringing this up again, since the results of the previous poll did
>not give an unambiguous result. Related links: [1], [2], [3], [4].
>
>Let me remind you that we are talking about adding the following macro.
>
>It is needed fo
Is it possible to contribute to this, even if you're not part of the core dev
team?
On January 10, 2016 11:43:48 AM CST, Brett Cannon wrote:
>For those of you who have not heard, I made the decision a little over
>a
>week ago to move Python's development from our home-grown workflow to
>one
>hos
On January 25, 2016 9:32:07 PM CST, INADA Naoki wrote:
>On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert
>wrote:
>
>> On Jan 25, 2016, at 18:21, INADA Naoki
>wrote:
>> >
>> > I'm very interested in it.
>> >
>> > Ruby 2.2 and PHP 7 are faster than Python 2.
>> > Python 3 is slower than Python 2
On January 25, 2016 9:59:36 PM CST, Chris Angelico wrote:
>On Tue, Jan 26, 2016 at 2:32 PM, INADA Naoki
>wrote:
>>
>> I know.
>> But people compares language speed by simple microbench like
>fibbonacci.
>> They doesn't use listcomp or libraries to compare *language* speed.
>>
>
>Well, that's a
win16 doesn't seem to have important stuff:
https://github.com/python/cpython/search?utf8=✓&q="win16";
On January 28, 2016 8:57:20 AM CST, Larry Hastings wrote:
>
>
>Check out and cd into Python trunk.
>
>% grep -Ri win16 * | wc
> 10 66 625
>
>% grep -Ri nextstep | wc
> 23
n
I hope you will all realize that this new idea is a drastic improvement
over current technologies and therefore support it, because we can Make
Python Great Again™.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Someth
Well, based on recent feedback, you should wait for Phyton 80, which will
also make your bean plants start growing hair.
(Side note: This is seriously weird. :O )
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 6, 2016 12:28 PM, "Brett Cannon" wrote:
>
> WIth Ethan volunteering to do the work to help make a path protocol a
thing -- and I'm
What is the value of HAS_ARG going to be now?
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 13, 2016 11:26 AM, "Victor Stinner" wrote:
> Hi,
>
> In the middle of recent discu
So code that depends on iterating through bytecode via HAS_ARG is going to
break...
Darn it. :/
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 13, 2016 4:44 PM, "Victor Stinner" wrote:
>
Oh wow, has a year passed already? I don't have access to an Android device
suitable for development, and Cyd seems to have disappeared, which is why
the issue ended up abandoned. I'd be happy to try to help with the new
effort if possible!
--
Ryan
[ERROR]: Your autotools build scrip
Well, I put this in Google Translate...and got this:
The disk clatters
the Spontie giggles
~
hopefully
alliance insures ...
Not sure if this a useless post or Translate just being weird. Leaning
towards the latter...
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
inished with exit code 1*
>
>
>
> Thanks and Regards
>
> Deepak Srivastava
>
>
>
>
Questions like this are better suited for python-list. Regardless, you need
to install Tesseract first:
https://github.com/tesseract-ocr/tesseract/wiki
That should fix the error
Well, the stack trace was pointing to the line that called Tesseract, so I
figured that was the problem.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On May 5, 2016 11:24 AM, "MRAB" wrote:
>
>
Wouldn't downloading the Microsoft C++ Runtime 2015 also work? Many recent
computers already have it pre-installed.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On May 25, 2016 2:31 PM, "Chris Bark
e path implies) just test data. A whopping >1k LOC
of really long hashes.
> Victor
>
> ___
> 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
https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>
--
Ryan
When your hammer is C++, everything begins to look like a thumb.
___
Python-Dev maili
_
> 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/rymg19%40gmail.com
>
--
Ryan
When your hammer is C++, everything begins to look like a
> On 2014-01-17, Ryan Gonzalez wrote:
> > A command line parameter??
>
> I believe it has to be global flag. A __future__ statement will not
> work. Probably we should allow the flag to be set with an
> environment variable as well.
>
> > The annoying part would b
mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>
--
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becau
___
> 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/rymg19%40gmail.com
>
>
--
Ryan
If anybody ever asks me why I pref
___
> 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/
> rymg19%40gmail.com
>
--
Ryan
If anybody ever asks me why I prefe
thon.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
--
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-
python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
--
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wai
://bugs.python.org/
>
>
> Enjoy!
>
>
> --
> Larry Hastings, Release Manager
> larry at hastings.org
> (on behalf of the entire python-dev team and 3.4's contributors)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pyt
il is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mai
er but has a longer warm-up time. Useful if the same
module is going to be reused several times.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
sense, same as spelling
> "Mercurial" as "hg".
>
...unless the reader doesn't know math. That would be
funny...*migrtoostarstarthree*
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pyth
at 1:30 AM, Chris Angelico wrote:
>
>> On Thu, Jun 12, 2014 at 7:58 AM, Ryan wrote:
>> > In all seriousness, to me this is obvious. When you pass a command to
>> the
>> > shell, naturally, certain details are shell-specific.
>>
>
> On Windows cm
> On Fri, Jun 13, 2014 at 2:55 AM, Ryan Gonzalez wrote:
>
>> SHELLS ARE NOT CROSS-PLATFORM Seriously, there are going to be
>> differences. If you really must:
>>
>> escape = lambda s: s.replace('^', '^^') if os.name == 'nt' else s
&
Type hints like in PEP 484 work on all Python 3 versions, and something
similar to your proposal is already supported on Python 2 [1].
[1]: https://mypy.readthedocs.io/en/latest/python2.html
On July 4, 2018 11:08:27 PM Shawn Chen wrote:
Hello,
Here, I am proposing a change on python type a
On July 6, 2018 5:04:05 PM Antoine Pitrou wrote:
(or contact the PEP's authors
privately).
Hoenstly, this feels like a recipe for a disaster...
As for the other kinds of threads, as much as I dislike PEP 572, they
are useless now.
Regards
Antoine.
On Fri, 6 Jul 2018 23:50:46 +0200
Vi
il.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
__
>> 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/guido%40python.org
>
>
n/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
Python-Dev mailin
y. I may be misunderstanding, but that's why a formal
approach for something like this might make some sense
Dan Ryan
gh: @techalchemy // e: d...@danryan.co
From: Q [mailto:qiang.f...@zoho.com.cn]
Sent: Friday, May 17, 2019 10:32 PM
To: Daniel Holth
Cc: Brett Cannon; Python-Dev
Subject: R
On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote:
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes to be used by the consumer. I want this duck
> to quack; so
>
> Makes sense. I'll change it to non-blocking, since this doc already uses
> "blocking" here and there to refer to the opposite effect.
>
> Eli
>
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@
> 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/rymg19%40gmail.com
>
--
Ryan
___
Python-Dev ma
overflow.com/a/3296782
> * http://code.activestate.com/recipes/66315-case-insensitive-dictionary/
> * https://gist.github.com/babakness/3901174
> * http://www.wikier.org/blog/key-insensitive-dictionary-in-python
> * http://en.sharejs.com/python/14534
> * http://www.voidspace.org.uk/pyt
gt; https://mail.python.org/mailman/options/python-dev/bill%40janssen.org
> ___
> 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/rymg19%40gmail.com
>
--
Ryan
___
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
ribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>
--
Ryan
___
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
> useful as a property of existing dictionaries. I often use
> case-insensitive keys. But I use them with dict and OrderedDict (and
> probably ought to use defaultdict, as well).
>
> TransformDict is neat, but I'd personally be happier seeing this as a
> 3rd party libra
;unpythonic" or similar?
> Regards,
>
> Neil
> ___
> 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/ry
hat this is entirely true.
> PEP 484 was about the syntax for types, declaring parameter and return
types, and declaring custom types to be generic.
> PEP 484 does include a description of type comments, but they are always
annotations on assignment statements and were primarily intended for use in
stub files.
>
>
>
> Please don&
Maybe the PEP should just say it's for "annotating variables", and it would
mention "primarily for the purpose of types"?
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Sep 5, 201
/?LinkId=550986> for
> Windows 10
>
>
>
> ___
> 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/
> rymg19%40gmail.com
>
>
--
R
Wonder if it's ever segfaulted...
...hey, I just figured out why we got Python 3! ;)
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Sep 7, 2016 2:02 PM, "Antoine Pitrou" wrote:
> On
:D
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Sep 7, 2016 1:20 PM, "Guido van Rossum" wrote:
> I'm accepting PEP 526 provisionally.
>
> I am personally confident that this PE
___
> 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/
> rymg19%40gmail.com
>
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than
E.g.:
import typing
print(typing.Pattern, typing.Match) # Works.
from typing import *
print(Pattern, Match) # NameError: name 'Pattern' is not defined
A quick look shows that typing.py doesn't have Pattern and Match in
__all__. Was this intentional, or just an oversight?
so gone:
https://wiki.python.org/PythonHumor
Being that the primary purpose is for proposing additions to the humor
list, I don't think archive.org would be of much help for this one.
--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone
exec -a would seem to end up setting argv[0] on the CPython interpreter
itself, which I don't think is the desired effect...
--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://refi64.com
On Mar 18, 2017 10:11 AM, "Freddy R
on how to freeze modules *using*
distutils, which is hardly helpful. FWIW, no one on the PR seemed to
mention that, either.
If distutils is indeed frozen, shouldn't it be documented somewhere in the
devguide?
--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawan
o/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
rymg19%40gmail.com
--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://refi64.com
___
Python-Dev mailing list
Python-D
are you ok to backport this change to Python
> 2.7, 3.5 and 3.6?
>
> I started with a backport to 3.6:
>
> https://github.com/python/cpython/pull/1461
>
>
> See also "Test somehow that generated files are up to date: run make
> regen-all" issue:
> http://bugs.
On Apr 8, 2022, 6:49 AM -0500, Greg Ewing , wrote:
> On 8/04/22 12:13 pm, Gregory P. Smith wrote:
> > And
> > for lurkers and subscribers here to enable email notifications for
> > categories of interest over there.
>
> Is it possible to participate in a Discourse discussion entirely
> by email, wi
On Tue, 17 Feb 2009 11:04:35 +1300, Greg Ewing wrote:
> Leif Walsh wrote:
>
>> If only we had a second Earth to mess with, we could just copy and
>> swap.
>
> Or we could use a generational approach, doing all our messy stuff
> around the moon and copying to earth when we've got our traffic cont
On Thu, 19 Feb 2009 21:41:51 -0600, Benjamin Peterson wrote:
> As we prepare to merge the io-c branch, the question has come up [1]
> about the original Python implementation. Should it just be deleted in
> favor C version? The wish to maintain the two implementations together
> has been raised on
On Mon, 23 Feb 2009 23:22:19 +, tav wrote:
> Steve, this isn't death by a 1,000 cuts. What's being put forward here
> is not a specific implementation -- but rather a specific model of
> security (the object capability model) -- which has been proven to be
> foolproof.
Proven? Isn't it imposs
Gisle Aas wrote:
On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:
On approximately 3/3/2009 11:22 PM, came the following characters from
the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
Steve Holden wrote:
Raymond Hettinger wrote:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
Issues:
Nick Coghlan wrote:
Lie Ryan wrote:
How about making odict ordered by insertion order, then provide an
optional argument for defining sorter? This optional argument must be a
function/lambda/callable object and must be the first argument.
or better yet, in the spirit of dumping cmp
Steven D'Aprano wrote:
I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.
"The keys don't expire with time."
"It's stable against accidental deletions."
"It's stable against accidentally over-writing values."
Add to that:
"The StableDict
Terry Reedy wrote:
Lie Ryan wrote:
Isn't ordered dictionary essentially also an "always sorted"
container? It is always sorted depending on the order of insertion? I
can't see any technical reason why the data structure can't
accommodate them both. Can you point m
Martin v. Löwis wrote:
The prize was Martin von Löwis of the Python Foundation on behalf of the
Python community itself.
This is a funny translation from German-to-English. :-)
But yeah, a good one and the prize was presented by Klaus Knopper of Knoppix.
Congratulations!
Actually, the prize
PEP 239 says that Rational type was Rejected, but some time ago this
decision is reverted, and now python 3.0 and python 2.6 includes a
fractions.Fraction type. Shouldn't this PEP be updated? (At least to
include a note of its obsoleted status or to point to the reversion)
Scott Dial wrote:
Aahz wrote:
On Wed, Mar 11, 2009, Antoine Pitrou wrote:
After Hrvoje's message, let me rephrase my suggestion. Let's instead allow:
open(..., sync_on="close")
open(..., sync_on="flush")
with a default of None meaning no implicit syncs.
That looks good, though I'd prefe
James Y Knight wrote:
On Mar 11, 2009, at 11:40 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
It is not the goal to replace locale or to accomodate every
possible convention. The goal is to make a common task easier
for many users. The current, default use of the period as a decimal
point
Steven D'Aprano wrote:
On Fri, 13 Mar 2009 01:02:26 pm R. David Murray wrote:
On Fri, 13 Mar 2009 at 00:35, Antoine Pitrou wrote:
R. David Murray bitdance.com> writes:
Seriously, though, the point is that IMO an application should not
be calling fsync unless it provides a way for that behavio
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Moore wrote:
2009/3/13 Chris Withers :
If a decent package management system *was* included, this wouldn't be an
issue..
Remember that a "decent package management system" needs to handle
filling in all the forms and arrang
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lie Ryan wrote:
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Moore wrote:
2009/3/13 Chris Withers :
If a decent package management system *was* included, this wouldn't be an
issue..
Remember t
Raymond Hettinger wrote:
I concur. Numbers are naturally right aligned.
Isn't numbers are "naturally right aligned" because of the Big Endian
notations that most mathematicians currently use. Had we been using
Little Endian notation, numbers would be naturally left-aligned,
wouldn't they?
Michael Foord wrote:
Benjamin Peterson wrote:
2009/10/5 Nick Coghlan :
So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
>
I've tried 4.__add__ a few times
On 05/08/10 03:57, Steve Holden wrote:
> Steven D'Aprano wrote:
>>
>> [...]
>>> Similarly, if you wanted p1==p2, why not write
>>>
>>> p1 = partial(operator.add)
>>> p2 = p1
>>
>> I thought the OP gave a use-case. He's generating "jobs" (partial
>> applied to a callable and arguments), and
On 05/21/10 15:18, Yaniv Aknin wrote:
> I would if I were qualified, but I an mot. One way to get people to help
>> with details is to publish mistakes. This happens all the time on
>> python-list ;-). Pre-review would be nice though.
>>
>
> I don't mind so much the 'humiliation' of published mist
Hi
I just got accepted on the google summer of code to work on a project
for python. I just wanted to say hello to everyone out there as i know
i will end up asking a few questions before the summers over.
--
Ryan Kelley
NETS - University of Rhode Island Network Security
http://www.uri.edu
SET_TOP(x);
if (x != NULL) DISPATCH();
break;
The implementation of PyObject_GetItem doesn't appear to have changed
though. Maybe this optimisation was no longer worth it in practice?
Ryan
--
Ryan Kelly
http://www.rfk.id.au | This message is digitally
/issue1093 .
If it is still wanted, could someone review it and give me feedback on it?
Thanks,
--
=====
--Ryan E. Freckleton
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
I'd like to propose an addition to the for statement's syntax:
for {variable} in {iterable} if {condition}:
{block}
which is equivalent to
for {variable} in {iterable}:
if not {condition}:
continue
{block}
and
for {variable} in filter(lambda: {condition}, iterable):
{bl
On Sun, May 21, 2006 at 17:38:49 CEST, Guido van Rossum wrote
> ...
> Also, it would be a parsing conflict for the new conditional
> expressions (x if T else y).
> ...
That's all I needed to know.
Sorry, everyone, I'll try not to waste your time in the future.
___
On Tue, 09 Dec 2008 12:15:53 -0500, Steve Holden wrote:
> Is anyone aware of any implementations that use other than 64-bit
> floating-point? I'd be particularly interested in any that use greater
> precision than the usual 56-bit mantissa. Do modern 64-bit systems
> implement anything wider than
I'm sure probably most of you knows about psyco[1], the optimizer. Python
has an -O and -OO flag that is intended to be optimization flag, but we
know that currently it doesn't do much. Why not add psyco as standard
library and let -O or -OO invoke psyco?
[1] http://psyco.sourceforge.net/index.
On Sat, 13 Dec 2008 13:28:37 +, Michael Foord wrote:
> Lie Ryan wrote:
>> I'm sure probably most of you knows about psyco[1], the optimizer.
>> Python has an -O and -OO flag that is intended to be optimization flag,
>> but we know that currently it doesn'
thanks for the reply hastings ive been working on a loopback interface its
done
On Fri, Jul 6, 2012 at 3:00 AM, wrote:
> Send Python-Dev mailing list submissions to
> python-dev@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mail
spoke too early on its done sorry
On Tue, Jul 10, 2012 at 2:04 PM, Ryan Paullin wrote:
> thanks for the reply hastings ive been working on a loopback interface its
> done
>
>
> On Fri, Jul 6, 2012 at 3:00 AM, wrote:
>
>> Send Python-Dev mailing list submissions
looks like theres no forgiveness except for dj yoda
On Thu, Jul 12, 2012 at 3:00 AM, wrote:
> Send Python-Dev mailing list submissions to
> python-dev@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/python-dev
> o
<- its just my gmail face
On Thu, Jul 12, 2012 at 3:30 AM, Ryan Paullin wrote:
> looks like theres no forgiveness except for dj yoda
>
>
> On Thu, Jul 12, 2012 at 3:00 AM, wrote:
>
>> Send Python-Dev mailing list submissions to
>> python-dev@python.org
>
meit -s 'import test' 'list(test.chunks(2,"abcdef"))'
10 loops, best of 3: 2.85 usec per loop
$ python -m timeit -s 'import test' 'test.chunks(2,"abcdef")'
100 loops, best of 3: 0.685 usec per loop
some woman wrote this
On Thu
I'm currently revising a proposal for the Google Summer of Code, and it
was suggested that I start a thread here to get input. Apologies for the
length, but I wanted this to more than just a link to my proposal.
The short version of my proposal is: The module would provide a
system by which the at
I'm currently revising a proposal for the Google Summer of Code, and it
was suggested that I start a thread here to get input. Apologies for the
length, but I wanted this to more than just a link to my proposal.
The short version of my proposal is: The module would provide a
system by which the ma
Apologies for the double post. Had my mail client misconfigured.
___
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.co
I'm not an official cpython developer but ifdef __ANDROID__ is quite in
line with other per-platform support (__FreeBSD__, __linux__, etc), as well
as already being in use in Modules/_posixsubprocess.c. Is __ANDROID__ not
being defined when it should be?
On Thu, Feb 26, 2015 at 4:20 PM,
On Thu, Feb 26, 2015 at 5:13 PM, Ryan Smith-Roberts wrote:
> I'm not an official cpython developer but ifdef __ANDROID__ is quite in line
> with other per-platform support (__FreeBSD__, __linux__, etc), as well as
> already being in use in Modules/_posixsubprocess.c. Is __ANDRO
I suspect that you will find the Python community extremely conservative
about any changes to its sorting algorithm, given that it took thirteen
years and some really impressive automated verification software to find
this bug:
http://envisage-project.eu/proving-android-java-and-python-sorting-alg
I favor a dual-mode approach. I think the existing behavior is best for the
conversion of existing modules, because it's easy to interactively verify
the generated code. Once that's done, long-term maintenance definitely
favors a more centralized format.
+1 _pickle.original.c /* used only during c
On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts wrote:
> NaN _pickle.using-sidefile.c /* not enough experience with it */
>
I hate to weasel like that. Intellectually I think I favor the sidefile
over all other approaches for its cleanliness. But I'd have to actively use
it in a
One of the downsides of converting positional-only functions to Argument
Clinic is that it can result in misleading docstring signatures. Example:
socket.getservbyname(servicename[, protocolname])
->
socket.getservbyname(servicename, protocolname=None)
The problem with the new signature is that i
On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts wrote:
> socket.getservbyname(servicename[, protocolname])
> ->
> socket.getservbyname(servicename, protocolname=None)
>
Here is a more complicated example, since the above does technically have
an alternative fix:
sockobj.
Let me expand on the issue, and address some of the replies.
The goal of Argument Clinic is to create new docstring signatures for
builtins, with the following properties:
1) Useful. While one can create a signature of func(*args) and then
document complex and arbitrary restrictions on what args
101 - 200 of 208 matches
Mail list logo
