Hello! And welcome aboard this mailing list ship. :)
___
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'm -1 on turning this on by default.
As a Python developer, I want to be aware of when deprecations are
introduced, but I don't want the users of my library or application to
care or know if I don't address those deprecation warnings for a few
months or a year. The right solution for me here seem
On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan wrote:
> For interactive use, the principle ends up being "Code you write gives
> deprecation warnings, code you import doesn't" (which is the main
> aspect I care about, since it's the one that semi-regularly trips me
> up when I forget that Deprecati
We need a PPP!
___
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
Python Party Proposal!
___
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
This might be tricky for alternative Python implementations which
might compile regular expressions into something rather different.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
Thanks for writing this email. It's well written and it takes a lot of
character to stand up and say you went down the wrong road. While I'm
here - thanks also for all your work on core Python. As a Python user
I really appreciate it.
Schiavo
Simon
___
P
On Thu, Sep 6, 2018 at 5:06 PM Ryan Gonzalez wrote:
> Thought: what if there's a label on the bug tracker meaning roughly "we're
> probably not going to fix this anytime soon, but we won't mind someone
> stepping up"?
Maybe "wouldlikehelpfixing"? :D
_
Are there any core devs that Michael or Erik could collaborate with?
Rather than rely on adhoc patch review from random core developers.
Michael and Eric: Question -- are you interested in becoming core
developers at least for the purposes of maintaining these platforms in
future?
I would consider it a feature. My reasoning is that the restriction on
what can be used as an identifier is a syntax restriction, not a
general restriction on what attributes or names can be.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
It feels like it would be a good idea for Brian or someone else from
Wind River to work towards becoming a core developer? If Brian, et al
are interested, is there a core developer who would be willing to
mentor them?
___
Python-Dev mailing list
Python-De
Software that "Just Works" and hasn't needed maintenance in years is the
best software. :D
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-d
Woot. +100 on this PEP.
> If the stdlib didn't have NNTP support, obviously nobody would suggest
> adding it nowadays.
Perhaps this is a good reason to keep nntplib in the deprecation list?
Another question is "are there any places using nntplib where `pip install
nntplib`" is not an reasonable o
As the maintainer of Genshi, one the libraries affected by the CodeType and
similar changes, I thought I could add a users perspective to the
discussion:
Genshi is a templating engine that parses Python code from inside its
templates. It supports Python 2.6+, 3.2+, pypy2 and pypy3. It parses Pytho
On Sat, Jun 1, 2019 at 12:29 AM Terry Reedy wrote:
> We try not to. There is already too much work.
> ...
> That was removed from the PR before it was merged.
> ...
> That was merged.
> ...
> Another chunk was added to What's New.
>
Woot to all of these! :)
_
Is there a way for people to give input to the challenges facing Python
discussion? I'm picturing something like people writing short statements of
perceived challenges and submitting them so that the SC has more ideas on
its radar.
___
Python-Dev mailing
can consider
almost any suggestion for improving HPy because none of the design is
set in stone. In a few months it might be helpful to have people try
porting some (many) C extensions to HPy to see how that goes.
Yours happily,
Simon Cross (random p
On Wed, Oct 21, 2020 at 4:28 AM Terry Reedy wrote:
> I don't think the two projects are mutually exclusive.
100% agreed. I would even go as far as to say that HPy and other
proposals to improve Python are mutually beneficial. HPy aims to
remove dependencies between C extensions and Python interna
I really enjoyed learning from this "user manual with a strong
narrative component" so I would personally like to see it stay even if
a new tutorial is created for a different kind of audience.
___
Python-Dev mailing list -- python-dev@python.org
To unsub
On Mon, Nov 9, 2020 at 6:38 PM Chris Angelico wrote:
> The name "tutorial" definitely screams "thing you should go through
> first". It shouldn't have to teach you everything. Keep the tutorial
> simple.
That's quite subjective. Personally I prefer a more complete tutorial
which explains many det
+1e6 + 5j # :)
___
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/python
ou're trying to solve).
Will hold thumbs that you find someone to review and merge the patch!
Yours sincerely,
Simon Cross
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail
The PR already has a fair amount of good review and discussion. Me
doing a superficial review is not going to help get it merged.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail
Thank you release team and all the bug fix contributors!
___
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
ht
On Wed, Dec 9, 2020 at 2:17 PM Ronald Oussoren via Python-Dev
wrote:
> We know. Backporting the relevant changes to 3.8 is taking more time than I
> had hoped. It doesn’t help that I’ve
> been busy at work and don’t have as much energy during the weekend as I’d
> like.
Thank you for all your ha
that head in the right direction and also
ensure that HPy is aligned with the immediate future of the C API.
Yours sincerely,
Simon Cross
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
On Mon, Jan 25, 2021 at 1:30 AM Terry Reedy wrote:
> The Python Software Foundation currently has a shortfall of funds rather
> than a surplus.
I believe Mark's proposal suggested raising money specifically for the
project, not spending general PSF funds.
_
On Thu, Mar 25, 2021 at 9:01 PM Mark Shannon wrote:
> Maybe the problem is the term "stealing".
> The caller is transferring the reference to the callee.
> In some circumstances it can make a lot of sense to do so, since the
> caller has probably finished with the reference and the callee needs a
I (with a lot of help and input from other people) wrote up some of
the thinking behind these kinds of API issues for the HPy project --
https://github.com/hpyproject/hpy/wiki/c-api-next-level-changes#what-needs-to-change-and-why
It's written from an HPy point of view and if you've already thought
Replying to the original email because my comment is more a thought
after reading the whole thread rather than a response to any
particular message.
What I love about __version__ is that it is simple. It doesn't come
with the complexity of solutions like `importlib.metadata.version`.
The maintaine
Replying to myself to update my own thoughts:
I think __version__ and packaging tools answer separate questions.
__version__ answers the question of "this module I imported, what
version is it".
The packaging tools answer the question "what dependency does this
distribution satisfy".
This misma
On Thu, Jun 3, 2021 at 4:16 AM Victor Stinner wrote:
> I would say that HPy is not complete nor mature yet. IMO it's already
> worth it to start playing with it, try to convert your small C
> extensions, and send back your early feedback to HPy developers!
This is my view of the state of HPy too.
On Thu, Jun 17, 2021 at 11:36 PM Pablo Galindo Salgado
wrote:
> #And now for something completely different
>
> There are no green stars. Why?
Thank you! This addition was great. :D
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe sen
On Thu, Aug 19, 2021 at 4:15 AM Tim Peters wrote:
> If you want more active moderation, volunteer for the job. I'd happily
> give it up, and acknowledge that my laissez-faire moderation approach
> is out of style.
I, for one, welcome your laissez-faire moderation approach. :D
a bit ominous. Is the
Steering Council considering removing python-dev? Eek.
Yours sincerely,
Simon Cross
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/
Hi Brett,
Thank you for the quick reply.
On Thu, Aug 26, 2021 at 8:58 PM Brett Cannon wrote:
> Marco was given a previous 3 month suspension on discuss.python.org (as Marco
> himself pointed out on the email thread in question). Speaking for myself,
> Marco was given a chance previously to tak
On Wed, Aug 25, 2021 at 9:28 PM Brett Cannon wrote:
> I just wanted to apologize for any angst or noise my replies to Marco caused
> folks.
Caring enough to write this email shows that you are an awesome human
(like many other humans). :D
Please don't feel too bad about getting some mud on your
less painful PEP
review process.
Thank you for writing PyOxidizer and offering some of your time to
help make Python itself better.
Yours sincerely,
Simon Cross
P.S. I am not a core developer, and I haven't even written any PEPs. :)
___
Python-D
Thank you for managing the release, Pablo!
And for the awesome astrophysics snippets. :D
___
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.py
Having a standalone version of IDLE might be really useful to
alternative Python implementations.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
I've used __subclasses__ as an easy way to register components by
sub-classing a base component. I didn't rely on the ordering. I guess
the current order depends on the order in which modules are imported
and so is pretty fragile anyway?
___
Python-Dev ma
On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou wrote:
> Because this API is mostly useful when the data is received (*) at a
> slow enough speed - which usually means from the network, not from a
> hard drive.
It looks like all the events have to be ready before one can start
iterating over .eve
On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote:
> What do you mean, "all events have to be ready"?
> If you look at the unit tests, the events are generated on-the-fly,
> not at the end of the document.
> (exactly the same as iterparse(), except that iterparse() is blocking)
So you have to
On Mon, Sep 30, 2013 at 1:51 AM, Larry Hastings wrote:
> My guess is, a lot of people would be disappointed if Tulip missed 3.4. I
> suspect the community would rather we slip the beta a little if it meant it
> the difference between Tulip and no Tulip.
+1
___
Yay!
___
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
On Tue, Jun 14, 2016 at 8:42 PM, Terry Reedy wrote:
> Thank you for finding that. I reread it and still believe that bytes was
> the right choice. Base64 is an generic edge encoding for binary data. It
> fits in with the the standard paradigm as a edge encoding.
I'd like to me-too Terry's sent
On Fri, Nov 4, 2016 at 9:56 AM, Eric V. Smith wrote:
> 2. The parser sees that it's an f-string, and breaks it into expression and
> text parts.
I'm with Fabio here. It would be really nice to have a grammar
specified and documented for this step, even if it's not implemented
that way. Otherwise
What about "CoroutineScope" or "CoroutineContext"?
___
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 thought the decision a few years ago was that all modules that have a C
library for performance reasons should also have a Python version? Did this
decision change at some point? (just curious).
___
Python-Dev mailing list
Python-Dev@python.org
https://
On Sun, Oct 10, 2021 at 4:23 PM Facundo Batista
wrote:
>
> struct.pack_into(format, buffer, offset, v1, v2, ...)
I've encountered this wart with pack and pack_into too.
The current interface makes sense when if v1, v2 are a small number of
items from a data record, but it becomes a bit silly
> Still, I hope you at least enjoyed my enthusiasm!
I did!
___
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
It's really great to see data being gathered on the impact of changes.
As we've already seen in this thread, there are many suggestions for how to
gather more data and thoughts on how the methodology might be enhanced --
and these suggestions are great -- but just having a means to gather some
imp
> tl; dr Python no longer leaks memory at exit on the "python -c pass" command
> ;-)
Whooohooo! :D
___
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/py
+10 on making the tier platform support explicit.
I would vote not to require involving the SC in the tier changes
unless there is a strong reason to do so (e.g. there is controversy,
or e.g. Tier 1 implies a commitment of PSF infrastructure). The SC has
a lot of decisions to make as it is & hopef
I'm -1 on moving to the walled garden, but I don't expect this to change
anyone's mind. I don't know if I'll move over to Discourse or not.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
> I can now pull from Discourse or GH when it’s convenient for me. It’s also
> much easier to disengage for a few days and catch up later.
I have a question about how you handle multiple communities. I'm
subscribed to ~30 python-dev style mailing lists across different
projects. There is no way
On Tue, Dec 3, 2019 at 7:42 PM Guido van Rossum wrote:
> I think it’s too soon to worry about this. I don’t see a reason to harass
> people who maintain code based that were just recently migrated.
>
+100
___
Python-Dev mailing list -- python-dev@pytho
Maybe we can have a two-for-one special? You can add a new function to the
API if you deprecate two.
___
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/py
On Fri, Jul 3, 2020 at 4:42 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> And since the PEP has Guido's authority behind it, I think
> it is likely that it will eventually be accepted pretty much as it was
> originally written.
>
This seems a bit unfair to Guido. He seems to put
I don't know if they suit your purposes, but both sqlite3 and a small array
implementation are already available:
https://github.com/micropython/micropython-lib/tree/master/sqlite3
https://github.com/v923z/micropython-ulab
___
Python-Dev mailing list --
On Sun, Oct 4, 2020 at 8:34 PM Mariatta wrote:
> Perhaps we can relax the rule to allow administrators to merge the stuck PRs.
> At least
> temporarily until Travis/GitHub fixes it. Does this sound okay?
+1 on relaxing the rule permanently. We should not give robots more
rights than humans.
Peo
Yay! Thanks Larry!
And they were two of the releases which really helped Python 3 take off. :D
___
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-
On Wed, Apr 22, 2009 at 8:50 AM, "Martin v. Löwis" wrote:
> For Python 3, one proposed solution is to provide two sets of APIs: a
> byte-oriented one, and a character-oriented one, where the
> character-oriented one would be limited to not being able to represent
> all data accurately. Unfortunate
On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman wrote:
> The goal of Unicode users everywhere is to use Unicode for everything, no?
> After all, all "real" file should have Unicode based names, and the only
> proper byte sequences that should exist are UTF-8 encoding Unicode bytes.
> (Cheek to
On Fri, Apr 24, 2009 at 11:22 AM, Glenn Linderman wrote:
> Oh clearly it is a hack. The right solution of a Path type (and friends)
> was discarded in earlier discussion, because it would impact too much
> existing code. The use of bytes would be annoying in the context of py3,
> where things th
On Mon, Apr 27, 2009 at 9:48 PM, "Martin v. Löwis" wrote:
> As Cameron says: it's out of the scope of the PEP. It really depends how
> the operating system deals with them. Most likely, the files are not
> accessible - not only not from Python, but also not accessible from
> any other Unix program
On Fri, Sep 4, 2009 at 1:11 PM, Chris Withers wrote:
> Am I right in reading this as most of the time is being spent in httplib's
> HTTPResponse._read_chunked and none of the methods it calls?
>
> If so, is there a better way that a bunch of print statements to find where
> in that method the time
On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé wrote:
> = Virtualenv and the multiple version support in Distribute =
...
> My opinion is that this tool exists only because Python doesn't
> support the installation of multiple versions for the same
> distributions.
This is not at all how I use vir
On Thu, Jan 7, 2010 at 1:12 PM, Lennart Regebro wrote:
> I'm not a license lawyer, but typically your company needs to give the
> code to the community. Yes, it means it stops owning it.
This is incorrect.
The correct information is at http://www.python.org/psf/contrib/.
Schiavo
Simon
_
On Thu, Jan 14, 2010 at 11:23 AM, Vinay Sajip wrote:
> So, can you please indicate your vote for or against incorporating PEP 391
> into Python?
I think the dict configuration scheme will be a great addition to the
logging module. :)
Schiavo
Simon
___
On Sun, Jan 31, 2010 at 1:54 PM, Hanno Schlichting wrote:
> I'd be a big +1 to using a single ".pyr" directory per source directory.
I don't know whether I in favour of using a single pyr folder or not
but if a single folder is used I'd definitely prefer the folder to be
called __pyr__ rather tha
On Sun, Jan 31, 2010 at 2:13 PM, Hanno Schlichting wrote:
> On Sun, Jan 31, 2010 at 1:03 PM, Simon Cross
> wrote:
>> I don't know whether I in favour of using a single pyr folder or not
>> but if a single folder is used I'd definitely prefer the folder to be
>&g
On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou wrote:
> Since there might be several compiled files for a single source file (for
> example, a .pyc along with a JITted native .so), __cache__ should probably be
> a
> tuple rather than a string.
But presumably there is only one compiled file that
On Fri, Feb 19, 2010 at 7:40 AM, "Martin v. Löwis" wrote:
>> Which most probably puts elementtree in bugfix-only mode. I don't
>> necessarily disagree with such a decision, but it must be quite clear.
The current situation is even worse than bugfix-only mode. Even
bugfixes struggle to make it in.
On Sat, Feb 20, 2010 at 9:57 AM, "Martin v. Löwis" wrote:
>> We need someone to maintain the copy of ElementTree in the Python
>> repository.
>
> We have one: Fredrik Lundh.
The last commits by Fredrik to ElementTree in Python SVN that I can
see are dated 2006-08-16. The last commits I can see to
On Sat, Feb 20, 2010 at 2:03 PM, "Martin v. Löwis" wrote:
> I'd rather drop ElementTree from the standard library than fork it.
Fork what? Upstream ElementTree is dead.
Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
On Thu, Jul 1, 2010 at 10:33 AM, Anders Sandvig
wrote:
> 2) Modify HTTPConnection.connect() to set the timeout on the socket
> object after it has been created (using the same timeout as given on
> the HTTPConnection constructor).
It looks like urllib2 in trunk and urllib.request in py3k are als
On Mon, Jul 5, 2010 at 11:05 PM, Nick Coghlan wrote:
> As Brett noted, yes, the LICENSE file is complicated, but most people
> don't bother reading it themselves - they ask what FSF and OSI think
> of it, and get the answers "BSD style" and "GPL compatible" and are
> happy with that.
Presumably a
On Tue, Jul 6, 2010 at 11:05 PM, Terry Reedy wrote:
> 1. Python License
>
> If there is not already, could there be an explanatory note, something like
> (worded to be 'neutral':
As a sub-point, I'd like to see something short explaining how the
different licenses in the LICENSE file are meat to
On Tue, Jul 13, 2010 at 12:26 AM, John Arbash Meinel
wrote:
r"testing \" backslash and quote"
> 'testing \\" backslash and quote'
>
> It happens that this is the behavior I want, but it seemed just as
> likely to be an error. I tested it with python2.5 and 2.6 and got the
> same results.
The
On Tue, Jul 20, 2010 at 12:29 AM, Steve Holden wrote:
> Another potential developer walks away feeling unwanted?
Let just kill this thread here. SIGKILL can't be caught. :)
(I had sort of assumed that Marcos was being ironic).
Schiavo
Simon
___
Python
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson wrote:
> Namespace conflict with what? I would prefer "wraps" unless it's
> standardized as a behavior for all decorators.
Having the original function available as __wrapped__ would be really
cool, although I'm not quite sure what the behaviour
On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano wrote:
>> * The decorator returns the original function (I suppose a reference
>> to itself is okay?)
>
> There's no reason why a function can't have an attribute that refers to
> the function itself. It works fine:
Yes. But it's more common for th
On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan wrote:
> However, as I noted before, these kinds of scenario are the reason we
> decided that building this feature directly into the decorator
> machinery wasn't a good idea.
I agree. I was just replying to Steven's response to my post. :)
Schiavo
On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote:
> from ...sys import path
>
> Note that while that last case is legal, it is certainly
> discouraged ("insane" was the word Guido used).
Only if by "legal" you mean "happened to work". It stops "happening to
work" in Python 2.6.6. :)
General
2010/10/28 Kristján Valur Jónsson :
> But the patient is very much alive and kicking, no matter what the good
> doctor declares.
No no! 'E's pining!
Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
wrote:
> (a) Python 3 doesn't support non-ASCII module names
-0: I'm vaguely against this being supported because I'd rather not
have to deal with what happens when the guess regarding the filesystem
encoding is wrong. On the other hand, a general
On Wed, Jan 19, 2011 at 10:32 PM, Terry Reedy wrote:
> I am a little shocked at the so-far tepid response to (a), so let me
> defend and explain my claim that it is a bug.
>
> In the simplest case (from 6.11. The import statement and 2.3. Identifiers
> and keywords)
>
> import_stmt ::= "import" m
On Wed, Jan 19, 2011 at 5:01 PM, Simon Cross
wrote:
> On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
> wrote:
>> (a) Python 3 doesn't support non-ASCII module names
>
> -0: I'm vaguely against this being supported because I'd rather not
> have to deal with w
On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik wrote:
> How about patches sent by users who track and fix bugs directly in
> codebase of their Python installation?
While I don't personally endorse the above approach, if you're going
to develop inside your installed site-packages folder it see
Hi Sam
On Wed, Feb 2, 2011 at 5:55 PM, Sam Bull wrote:
> This is my first stab at contributing to this list. I'm writing to lobby for
> bug #8797's fix to be removed and for my fix to put in in its place.
For what it's worth, I was already about to include your patch as a
workaround for the bug
On Fri, Mar 4, 2011 at 2:58 AM, Victor Stinner
wrote:
> Some months ago, I proposed a patch to display the Python backtrace on a
> segfault. The API was not stable, it was too for Python 3.2, and it was
> enabled by default. I wrote a module instead of a patch so it can be
> used on any version of
On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner
wrote:
> faulthandler is also a little bit special, because it is very specific
> to CPython: it is based on CPython internal structures.
If faulthandler is a public part of the standard library, what should
other Python implementations do about impl
On Wed, Mar 23, 2011 at 7:24 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 10:25:01 -0700
> Ethan Furman wrote:
>>
>> I think the use-case has been lost. Think sprints and multiple push
>> races. No one is arguing that the smoke-test should be the default, but
>> seriously, are you willing to
On Fri, Mar 25, 2011 at 1:25 AM, Nick Coghlan wrote:
> As an example of the last point, perhaps rather than modifying all the
> *clients* of the socket module, it may make more sense to have tools
> in the socket module itself to temporarily customise the socket
> creation process in the current t
On Thu, Mar 31, 2011 at 12:54 AM, Nick Coghlan wrote:
> Interesting - it comes straight up with the folded screen for me, no
> flickering at all.
I didn't get any flicker either and my first impression of the change
was also positive -- I usually skip straight to the comments the first
time I vis
On Tue, May 27, 2008 at 12:43 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Ten minutes ago I raised a concern about speed differences between the
> old style % formatting and the new .format() code. Some quick
> benchmarking from Benjamin and me showed, that it's even worse than I
> expected.
Originally Python exceptions had no __unicode__ method. In Python 2.5
__unicode__ was added. This led to "unicode(Exception)" failing and so
the addition of __unicode__ was reverted [1].
This leaves Python 2.6 in a position where calls to
"unicode(Exception(u'\xe1'))" fail as they are equivalent t
On Wed, Jun 11, 2008 at 11:34 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 4) Fix PyObject_Unicode to not retrieve __unicode__ from new-style
> instances, and instead only look for the method on their types (similar to
> the way PyObject_Format looks up the __format__ method).
Thanks for the sugg
On Thu, Jun 12, 2008 at 11:48 AM, anton <[EMAIL PROTECTED]> wrote:
> ping works but http://bugs.python.org giges after a timeout:
Seeing the same thing here, so it's not just you.
Schiavo
Simon
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
1 - 100 of 135 matches
Mail list logo
