things up by removing the S&W guideline could've
been trivially accomplished without generating any of this drama.
It's baffling claim to promote cohesion and throw a partisan diatribe
into the commit message.
Mmm. Well, we said what we had to say.
I think this captures the r
On Thu, Apr 02, 2020 at 08:57:30PM -0700, Guido van Rossum wrote:
> On Thu, Apr 2, 2020 at 7:55 PM Matt Billenstein wrote:
>
> Even just running it in a dev build against the corpus of the top few
> thousand packages on pypi might give enough confidence -- I had a scr
e top N packages and run some script over the python files
contained therein, but I can't seem to find it atm.
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
Thanks Ned - confirmed that works in 2.7.17 - maybe it was there in
2.7.16 and I just overlooked that messaging in the last step.
m
On Mon, Mar 23, 2020 at 09:11:09PM -0400, Ned Deily wrote:
> On Mar 23, 2020, at 20:30, Matt Billenstein via Python-Dev
> wrote:
> > Hi, installin
- perhaps the installer
should ship a bundle or enable using something like certifi if it's
installed?
AFAIK Apple has deprecated openssl libs as shipped with the OS a long
time ago and only support their proprietary framework crypto apis and on
MacOS Catalina and newer.
thx
m
--
path/to/source/python -m venv
> env_dir.
I'd suggest https://github.com/pyenv/pyenv -- this handles this more
seamlessly.
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscri
ursor.fetchall()
...
[{'notes': 'hi there'}]
[{'notes': '\\x6869207468657265'}]
We were storing the response of an api request from requests and had grabbed
response.content (bytes) instead of response.text (str). I was still able to
decode the original data fro
ing __builtins__.str with something that asserts the given arg is not
bytes.
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
htt
On Tue, Aug 06, 2019 at 04:32:04PM +, Matt Billenstein wrote:
> Perhaps those packages could be flagged now via pylint and problems raised
> with
> the respective package maintainers before the actual 3.8 release? Checking
> the
> top 100 or top 1000 packages on PyPI?
fwiw
n due to third-party packages
> (such as docutils and bottle) that users can't easily do anything about.
Perhaps those packages could be flagged now via pylint and problems raised with
the respective package maintainers before the actual 3.8 release? Checking the
top 100 or top 1000 packages
On Sun, Sep 9, 2018, 12:59 Antoine Pitrou wrote:
>
>
> I'm not sure why anyone would ask that question.
because if they can discredit a witness, they will.
Matt
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
On Mon, Jul 2, 2018 at 2:34 AM Michael Selik wrote:
>
> On Sun, Jul 1, 2018 at 8:21 PM Matt Arcidy wrote:
>>
>> [...] Can anyone adequately explain why this specific modality of learning,
>> a student-in-a-seat based educator, must outweigh all other modalities [...]?
This cynical view on students is shocking! Everyone on this list has
been a student or a learner for far longer than an educator, and the
perspective from students and learners are far more important than
educators to assess this angle regardless. Can anyone adequately
explain why this specific m
As i recall git LFS makes storing large binary objects in some external object
storage fairly seamless - might be a good fit for keeping the same workflow and
not bloating the repo.
M
--
Matt Billenstein
m...@vazor.com
Sent from my iPhone 6 (this put here so you know I have one)
> On Mar
DEBUG
-g
-fwrapv
-O3
-Wall
-Wstrict-prototypes
python3-config -ldflags;
-L/nfs/sc/disks/slx_1353/mlpriest/sl1/work_root/a0/development/sfwr/lib/python3.6/config-3.6m-x86_64-linux-gnu
-L/nfs/sc/disks/slx_1353/mlpriest/sl1/work_root/a0/development/sfwr/lib
-lpython3.6m
-lpthread
-ldl
-lutil
-lr
ping the
headers for things like ssl and ffi since they don't want 3rd parties linking
to deprecated versions of those libraries versus, in the case of ssl, their
newer security framework. Recommendation is to bundle what you need if you're
not using the framework -- something to think about.
On Sun, Jan 14, 2018 at 10:54:57AM -0500, Ned Deily wrote:
> On Jan 14, 2018, at 08:39, Christian Heimes wrote:
> > On 2018-01-14 09:24, Matt Billenstein wrote:
> >> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has
> >> deprecated (and
egards,
>Christian
> ___
> 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/matt%40vazor.com
--
Matt
Common pattern I've used is to wait a bit, then send a kill signal.
M
--
Matt Billenstein
m...@vazor.com
Sent from my iPhone 6 (this put here so you know I have one)
> On Aug 11, 2017, at 5:44 AM, Victor Stinner wrote:
>
> Hi,
>
> I'm working on reducing the f
On Tue, May 16, 2017 at 11:31:42AM +0100, Martin Wimpress wrote:
> Is there someone here who'd be interested in doing the same for Python?
Do snaps support Windows and/or MacOS?
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
__
I raised this issue and question on StackExchange and #python (FreeNode)
and have received little or no feedback. I fear that the only answer
will lie in profiling the python interpreter itself, which is beyond the
scope of my capabilities at present.
The original question can be found here:
ppreciate everyone's hard work - I'm confident the community will cross the
2-3 chasm and I hope we preserve the approachability I first came to love about
Python when I started using it for all sorts of applications.
thx
m
--
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
ittest2/compare/issue11798-tip..issue11798-base#diff
[2]: https://code.google.com/p/unittest-ext/issues/detail?id=76&sort=-id
[3]: https://pypi.python.org/pypi/unittest2
--
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
backport to unittest2?
--
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/
On Aug 3, 2013, at 12:07 PM, "R. David Murray" wrote:
> Thanks. Please post your patch to the issue, it will get lost here.
I'm trying to register, but I'm not receiving a confirmation email to complete
the registration.
--
http://matthewlmcclure.com
http://about.mapmyfitness.com
_
crack at the docs.
# HG changeset patch
# User Matt McClure
# Date 1375538965 14400
# Node ID d748d70201929288c230862da4dbdba33d61ae9f
# Parent bf43956356ffe93e75ffdd5a7a8164fc68cf14ae
[11798] Document TestSuite.{__iter__, run} changes
diff --git a/Doc/library/unittest.rst b/Doc/library/unitt
;ll see if I can contribute
there.
--
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
nversation on django-developers[1] that led me here.
[1]: https://groups.google.com/forum/#!topic/django-developers/XUMetDSGVT0
--
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
Python-Dev mailing list
On Thursday, May 16, 2013 08:41:32 PM you wrote:
> On Fri, May 17, 2013 at 1:38 PM, Nick Coghlan wrote:
> > On Fri, May 17, 2013 at 9:17 AM, Matt Newell wrote:
> >> I don't really understand what the fixup_slot_dispatchers function is
> >> doing, but it does seem
seem like there must be a bug either in what it's doing, or in
PyNumber_InPlaceAdd's handling of a NotImplemented return value from
sq_inplace_concat.
Thanks,
Matt
Python 2.7.3 (default, Jan 2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Stack trace where a watch on sq->sq_inplace
On May 2, 2012 6:00 PM, "Antoine Pitrou" wrote:
>
> On Wed, 02 May 2012 01:43:32 -0700
> Larry Hastings wrote:
> >
> > I realize we can't jump to C99 because of A Certain Compiler. (Its name
> > rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even that
> > compiler added this extens
Cheers
On Apr 21, 2012 10:25 AM, "R. David Murray" wrote:
>
> On Sat, 21 Apr 2012 08:54:56 +0800, Matt Joiner
> wrote:
> > I'm getting one of these every couple of days. What's the deal?
> > On Apr 21, 2012 1:03 AM, "Python tracker" <
> &
I'm getting one of these every couple of days. What's the deal?
On Apr 21, 2012 1:03 AM, "Python tracker" <
roundup-ad...@psf.upfronthosting.co.za> wrote:
>
> An unexpected error occurred during the processing
> of your message. The tracker administrator is being
> notified.
>
> Return-Path:
> X-
Personally I find the unholy product of C and Python that is Cython to be
more complex than the sum of the complexities of its parts. Is it really
wise to be learning Cython without already knowing C, Python, and the
CPython object model?
While code generation alleviates the burden of tedious lang
This is becoming the Manhattan Project of bike sheds.
___
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
+1! Thanks for pushing this.
On Apr 15, 2012 4:04 AM, "Brett Cannon" wrote:
> To start off, what I am about to propose was brought up at the PyCon
> language summit and the whole room agreed with what I want to do here, so I
> honestly don't expect much of an argument (famous last words).
>
> In
On Apr 10, 2012 2:36 AM, "Terry Reedy" wrote:
>
>
> On 4/9/2012 9:13 AM, r.david.murray wrote:
>>
>> http://hg.python.org/cpython/rev/eff551437abd
>> changeset: 76176:eff551437abd
>> user:R David Murray
>> date:Mon Apr 09 08:55:42 2012 -0400
>> summary:
>> #14533: if a test has
Lock it in before the paint dries.
On Apr 4, 2012 10:05 AM, "Matt Joiner" wrote:
> Finally! We've come full circle.
>
> +1 for monotonic as just described by Victor.
>
___
Python-Dev mailing list
Python-Dev@python.org
htt
Finally! We've come full circle.
+1 for monotonic as just described by Victor.
___
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%40
The discussion has completed degenerated. There are several different
clocks here, and several different agendas.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
time.timeout_clock?
Everyone knows what that will be for and we won't have to make silly
theoretical claims about its properties and expected uses.
If no one else looks before I next get to a PC I'll dig up the clock/timing
source used for select and friends, and find any corresponding syscall th
time.monotonic(): The uneventful and colorless function.
On Mar 28, 2012 9:30 PM, "Larry Hastings" wrote:
> On 03/28/2012 01:56 PM, R. David Murray wrote:
>
>> On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano
>> wrote:
>>
>>> +1 on Nick's suggestion of try_monotonic. It is clear and obvious a
On Mar 28, 2012 8:38 AM, "Victor Stinner" wrote:
>
> Scott wrote:
>
> << The Boost implementation can be summarized as:
>
> system_clock:
>
> mac = gettimeofday
> posix = clock_gettime(CLOCK_REALTIME)
> win = GetSystemTimeAsFileTime
>
> steady_clock:
>
> mac = mach_absolute_time
> posix = clo
> I renamed time.steady() to time.try_monotonic() in the PEP. It's a
> temporary name until we decide what to do with this function.
How about get rid of it?
Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value. Finding out that someth
Cheers, that clears things up.
___
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
So does anyone care to dig into the libstd++/boost/windoze implementation
to see how they each did steady_clock?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
Inside time.steady, there are two different clocks trying to get out.
I think this steady business should be removed sooner rather than later.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
the text in the nav bar is too small, particularly in the search box.
___
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-archi
FWIW it doesn't hurt to err on the side of what worked. i have generally
have issues with low contrast, the current stable design is very good with
this.
i've just built the docs from tip, and the nav bar issue is fixed, nicely
done
i also don't see any reason to backport theme changes, +0
__
Not sure if you addressed this in your answers to other comments...
Scroll down the page. Minimize the nav bar on the left. Bring it back
out again. Now the text in the nav bar permanently starts at an offset
from the top of the page.
On Sun, Mar 25, 2012 at 7:44 PM, Matt Joiner wrote:
>
Is nice yes?! When I small the nav bar, then embiggen it again, the text
centers vertically. It's in the wrong place. The new theme is very minimal,
perhaps a new color should be chosen. We've done green, what about orange,
brown or blue?
___
Python-Dev m
Yes, call it what it is. monotonic or monotonic_time, because that's why
I'm using it. No flags.
I've followed this thread throughout, and I'm still not sure if "steady"
gives the real guarantees it claims. It's trying to be too much. Existing
bugs complain about backward jumps and demand a clock
The 24 core machine at my last workplace could configure and make the tip
in 45 seconds from a clean checkout.
Lots of cores? :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
Turn your monitor portrait or make the window smaller :)
___
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 believe we should make a monotonic_time method that assures monotonicity
and be done with it. Forward steadiness can not be guaranteed. No
parameters.
On Mar 20, 2012 2:56 PM, "Steven D'Aprano" wrote:
> On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote:
>
> > Said differently: time
Steven D'Aprano" wrote:
> Terry Reedy wrote:
>
>> On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
>>
>>> On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner
>>> wrote:
>>>
>>>> +1. I now prefer time.monotonic(), no flags.
>>&
+1. I now prefer time.monotonic(), no flags. It attempts to be as high
precision as possible and guarantees never to jump backwards. Russell's
comment is right, the only steady sources are from hardware, and these are
too equipment and operating system specific. (For this call anyway).
On Mar 16, 2
On Mar 15, 2012 4:23 PM, "Paul Moore" wrote:
>
> On 15 March 2012 01:58, Matt Joiner wrote:
> > Victor, I think that steady can always be monotonic, there are time
sources
> > enough to ensure this on the platforms I am aware of. Strict in this
sense
> > refers
Victor, I think that steady can always be monotonic, there are time sources
enough to ensure this on the platforms I am aware of. Strict in this sense
refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
CLOCK_MONOTONIC_RAW.
Non monotonicity of this call should be considered a bug. Strict
I also can live with steady, with strict for the flag.
___
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
FWIW the name is quite important, because these kind of timings are
quite important so I think it's worth the effort.
> - By default, it should fall back to time.time if a better source is
> not available, but there should be a flag that can disable this
> fallback for users who really *need* a
On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum wrote:
> I have a totally different observation. Presumably the primary use
> case for these timers is to measure real time intervals for the
> purpose of profiling various operations. For this purpose we want them
> to be as "steady" as possible:
> Can you give a pointer to these one-liners?
> Once a patch gets a month old or older, it tends to disappear from
> everyone's radar unless you somehow "ping" on the tracker, or post a
> message to the mailing-list.
All of these can be verified with a few minutes of checking the
described code pa
I have some observations regarding this:
Victor's existing time.monotonic and time.wallclock make use of
QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of
these are hardware-based counters, their monotonicity is just a
convenient property of the timer sources. Furthermore, time
Thanks for the suggestions.
On Mar 14, 2012 12:03 PM, "Eli Bendersky" wrote:
> > Rather than indicating apathy on the party of third party developers,
> this
> > might be a sign that core Python is unapproachable or not worth the
> effort.
> >
> > For instance I have several one line patches lang
On Mar 14, 2012 5:27 AM, "Antoine Pitrou" wrote:
>
> On Tue, 13 Mar 2012 14:16:40 -0700
> Guido van Rossum wrote:
>
> > On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy wrote:
> > > Authors of separately maintained packages are, from our viewpoint, as
> > > eligible to help with tracker issues as a
Definitely think some library vetting needs to occur. Superior alternatives
do exist and are difficult to find and choose from. Stuff like LXML,
Requests, Tornado are clear winners.
The more of this done externally (ie PyPI the better). I still think a set
of requirements for "official approval" w
+1 for won't fix.
On Feb 26, 2012 9:46 PM, "Antoine Pitrou" wrote:
> On Sun, 26 Feb 2012 14:27:21 +0100
> Stefan Krah wrote:
> >
> > The underlying problems with memoryview were intricate and required
> > a long discussion (issue #10181) that led to a complete rewrite
> > of memoryobject.c.
> >
Big +1
On Feb 26, 2012 4:41 PM, "Eli Bendersky" wrote:
>
> On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" wrote:
>
>> > I find that strange, especially for an expert Python dev. I, a newbie,
>> > find it far friendlier (and easier for a new programmer to grasp).
>> > Maybe it's because I use it
Chrome does something similar. All digits keep rising in that scheme.
However in your examples you can't identify whether bug fixes are to stdlib
or interpreter?
On Feb 26, 2012 10:07 AM, "Terry Reedy" wrote:
> We have two similar proposals, PEPs 407 and 413, to speed up the release
> of at least
addressing this. I would suggest Haskell, node.js and golang as
examples of how stdlibs are minimal enough to define basic idiomatic
interfaces but allow and encourage extension.
On Feb 25, 2012 10:53 AM, "Brett Cannon" wrote:
>
>
> On Fri, Feb 24, 2012 at 21:08, Matt Joiner wrote:
I think every minor release should be fully supported. The current rate of
change is very high and there's a huge burden on implementers and
production users to keep up, so much so that upgrading is undesirable
except for serious enthusiasts.
Include just the basics and CPython specific modules in
On Mon, Feb 20, 2012 at 11:27 PM, Antoine Pitrou wrote:
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request import
> urlopen").
>
> Historically, our stdlib has been flat and I think it should stay so,
> short of redoi
+1 for using symlinks where possible. In deploying Python to different
operating systems and filesystems I've often had to run a script to "fix"
the hardlinking done by make install because the deployment mechanism or
system couldn't be trusted to do the right thing with respect to minimising
insta
+1
On Feb 4, 2012 8:37 PM, "Paul Moore" wrote:
>
> On 4 February 2012 11:25, Steven D'Aprano wrote:
> > It strikes me that it would be helpful sometimes to programmatically
> > recognise "preview" modules in the std lib. Could we have a
recommendation
> > in PEP 8 that such modules should have a
Woohoo! :)
___
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
raise from None seems pretty "in band". A NoException class could have many
other uses and leaves no confusion about intent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
Analysis paralysis commence. +1 for separate module using decimal.
On Feb 1, 2012 1:44 PM, "PJ Eby" wrote:
> On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan wrote:
>
>> Such a protocol can easily be extended to any other type - the time
>> module could provide conversion functions for integers and
Nick mentioned using a single type and converting upon return, I'm starting
to like that more. A limited set of time formats is mostly arbitrary, and
there will always be a performance hit deciding which type to return.
The goal here is to allow high precision timings with minimal cost. A
separate
Sounds good, but I also prefer Alexander's method. The type information is
already encoded in the class object. This way you don't need to maintain a
mapping of strings to classes, and other functions/third party can join in
the fun without needing access to the latest canonical mapping. Lastly
the
It's also potentially lossy if you incremented and decremented until
integer precision is lost. My vote is for an int type check. No casting.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I think an advocacy of 3rd party modules would start with modules such as
ipaddr, requests, regex. Linking directly to them from the python core
documentation, while requesting they hold a successful moratorium in order
to be included in a later standard module release.
On Jan 30, 2012 10:47 AM, "N
> __preview__ would fall into this category as well). And yet I have
> essentially no means of gaining access to any 3rd party modules,
> whether they are packaged by the distro or obtained from PyPI. (And
> "build your own" isn't an option in many cases, if only because a C
> compiler may well no
> +1. I'd much rather just use the module from PyPI.
>
> It would be good to have a practical guide on how to manage the
> transition from third-party to core library module though. A PEP with
> a list of modules earmarked for upcoming inclusion in the standard
> library (and which Python version t
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable. Python core public releases are
no place for testing.
On Sat, Jan 28, 2012 at 2:42 AM, Matt Joiner wrote:
> On Fri, Jan 27, 2012 at 12:26 PM, Alex wrote:
>> I think a significa
On Fri, Jan 27, 2012 at 12:26 PM, Alex wrote:
> I think a significantly healthier process (in terms of maximizing feedback and
> getting something into it's best shape) is to let a project evolve naturally
> on
> PyPi and in the ecosystem, give feedback to it from an inclusion perspective,
> and
> A more normal incantation, as is often the way for packages that became
> parts of the standard library after first being a third party library
> (sometimes under a different name, e.g. simplejson -> json):
>
> try:
> from __preview__ import thing
> except ImportError:
> import thing
>
> So
+0. I think the idea is right, and will help to get good quality
modules in at a faster rate. However it is compensating for a lack of
interface and packaging standardization in the 3rd party module world.
___
Python-Dev mailing list
Python-Dev@python.org
After much consideration, and playing with PEP380, I've changed my
stance on this. Full blown coroutines are the proper way forward.
greenlet doesn't cut it because the Python interpreter isn't aware of
the context switches. Profiling, debugging and tracebacks are
completely broken by this. Stackle
Can calls to the C types in the io module be made into module lookups
more akin to how it would work were it written in Python? The C
implementation for io_open invokes the C type objects for FileIO, and
friends, instead of looking them up on the io or _io modules. This
makes it difficult to subcla
> My concern is that you will end up with vastly more 'yield from's
> than places that require locks, so most of them are just noise.
> If you bite your nails over whether a lock is needed every time
> you see one, they will cause you a lot more anxiety than they
> alleviate.
Not necessarily. The
On Fri, Jan 20, 2012 at 8:41 AM, Greg wrote:
> Glyph wrote:
>>
>> [Guido] mentions the point that coroutines that can implicitly switch out
>> from under you have the same non-deterministic property as threads: you
>> don't know where you're going to need a lock or lock-like construct to
>> update
PEP380 and Mark's coroutines could coexist, so I really don't "it's
too late" matters. Furthermore, PEP380 has utility in its own right
without considering its use for "explicit coroutines".
I would like to see these coroutines considered, but as someone else
mentioned, coroutines via PEP380 enhan
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl wrote:
> The main reason is changes in the library. We have been getting complaints
> about the standard library bitrotting for years now, and one of the main
> reasons it's so hard to a) get decent code into the stdlib and b) keep it
> maintained is
Just to clarify, this differs in functionality from enhanced generators by
allowing you to yield from an arbitrary call depth rather than having to
"yield from" through a chain of calling generators? Furthermore there's no
syntactical change except to the bottommost frame doing a co_yield? Does
thi
If minor/feature releases are introducing breaking changes perhaps it's
time to adopt accelerated major versioning schedule. For instance there are
breaking ABI changes between 3.0/3.1, and 3.2, and while acceptable for the
early adoption state of Python 3, such changes should normally be reserved
Great work Nick, I've been looking forward to this one. Thanks all for
putting the effort in.
On Fri, Jan 13, 2012 at 11:14 PM, Nick Coghlan wrote:
> I marked PEP 380 as Final this evening, after pushing the tested and
> documented implementation to hg.python.org:
> http://hg.python.org/cpython/r
On Thu, Jan 12, 2012 at 11:01 AM, Mike Meyer wrote:
> On Wed, 4 Jan 2012 00:07:27 -0500
> PJ Eby wrote:
>
>> On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer wrote:
>> > A suite is marked
>> > as a `transaction`, and then when an unlocked object is modified,
>> > instead of indicating an error, a lock
I suspect it actually would fix the confusion. "dev" usually means
development, not "core implementation development". People float past
looking for dev help... python-dev. Python-list is a bit generic.
On Tue, Jan 10, 2012 at 11:17 PM, Stefan Behnel wrote:
> Matt J
http://semver.org/
This has made sense since Gentoo days.
On Tue, Jan 10, 2012 at 11:57 PM, Antoine Pitrou wrote:
> On Tue, 10 Jan 2012 08:49:04 +
> Rob Cliffe wrote:
>> But "minor version" and "major version" are readily understandable to
>> the general reader, e.g. me, whereas "feature re
1 - 100 of 173 matches
Mail list logo
