Re: [Python-Dev] (no subject)

On 2019-04-10 22:00, Terry Reedy wrote: On 4/10/2019 7:24 AM, Robert Okadar wrote: Hi community, I have developed a tkinter GUI component, Python v3.7. It runs very well in Linux but seeing a huge performance impact in Windows 10. While in Linux an almost real-time performance is achieved, in W

Re: [Python-Dev] (no subject)

On 4/10/2019 7:24 AM, Robert Okadar wrote: Hi community, I have developed a tkinter GUI component, Python v3.7. It runs very well in Linux but seeing a huge performance impact in Windows 10. While in Linux an almost real-time performance is achieved, in Windows it is slow to an unusable level.

Re: [Python-Dev] (no subject)

Hi Steven, Thank you for pointing me in the right direction. Will search for help on places you mentioned. Not sure how can we help you with developing the Python interpreter, as I doubt we have any knowledge that this project might use it. When I say 'we', I mean on my colleague and me. All the

Re: [Python-Dev] (no subject)

Hi Robert, This mailing list is for the development of the Python interpreter, not a general help desk. There are many other forums where you can ask for help, such as the comp.lang.python newsgroup, Stackoverflow, /r/python on Reddit, the IRC channel, and more. Perhaps you can help us though,

Re: [Python-Dev] (no subject)

On Tue, Dec 26, 2017 at 2:01 AM, Yogev Hendel wrote: > > I don't know if this is the right place to put this, > but I've found the following lines of code results in an incredibly long > processing time. > Perhaps it might be of use to someone. > > import re > pat = re.compile('^/?(?:\\w+)/(?:[%\\

Re: [Python-Dev] (no subject)

On 2017-12-26 07:01, Yogev Hendel wrote: I don't know if this is the right place to put this, but I've found the following lines of code results in an incredibly long processing time. Perhaps it might be of use to someone. /import re/ /pat = re.compile('^/?(?:\\w+)/(?:[%\\w-]+/?)+/?$')/ /pat.

Re: [Python-Dev] (no subject)

Victor, Thanks - I will comment on the issue WRT backporting the fix. If you have particular issues you’d like me to look into, just point me in the right direction. Thanks, Rob On 6/30/17, 2:29 AM, "Victor Stinner" wrote: >Hi Robb, > >2017-06-29 23:34 GMT+02:00 Rob Boehne : >> I¹m new to

Re: [Python-Dev] (no subject)

I am still in favor of this PEP but have run out of time to review it and the feedback. I'm going on vacation for a week or so, maybe I'll find time, if not I'll start reviewing this around Feb 23. -- --Guido van Rossum (python.org/~guido) ___ Python-De

Re: [Python-Dev] (no subject)

Georg Brandl wrote: The call syntax part is a mixed bag: on the one hand it is nice to be consistent with the extended possibilities in literals (flattening), but on the other hand there would be small but annoying inconsistencies anyways (e.g. the duplicate kwarg case above). That inconsistenc

Re: [Python-Dev] (no subject)

John Wong wrote: I am actually amazed to remember dict + dict is not possible... there must be a reason (performance??) for this... I think it's mainly because there is no obviously correct answer to the question of what to do about duplicate keys. -- Greg __

Re: [Python-Dev] (no subject)

On 02/10/2015 10:33 AM, Paul Moore wrote: > On 10 February 2015 at 00:29, Neil Girdhar wrote: >>> > function(**kw_arguments, **more_arguments) >>> If the key "key1" is in both dictionaries, more_arguments wins, right? >> >> >> There was some debate and it was decided that duplicate keyword argumen

Re: [Python-Dev] (no subject)

I split off a separate thread on python-ideas [1] specific to the idea of introducing "+" and "+=" operators on a dict. [1] https://mail.python.org/pipermail/python-ideas/2015-February/031748.html ~ Ian Lee On Tue, Feb 10, 2015 at 10:35 PM, John Wong wrote: > > > On Wed, Feb 11, 2015 at 12:35

Re: [Python-Dev] (no subject)

On Wed, Feb 11, 2015 at 12:35 AM, Ian Lee wrote: > +1 for adding "+" or "|" operator for merging dicts. To me this operation: > > >>> {'x': 1, 'y': 2} + {'z': 3} > {'x': 1, 'y': 2, 'z': 3} > > Is very clear. The only potentially non obvious case I can see then is > when there are duplicate keys,

Re: [Python-Dev] (no subject)

On Wed, 11 Feb 2015 18:45:40 +1300 Greg Ewing wrote: > Antoine Pitrou wrote: > bytearray(b"a") + b"bc" > > > > bytearray(b'abc') > > > b"a" + bytearray(b"bc") > > > > b'abc' > > > > It's quite convenient. > > It's a bit disconcerting that the left operand wins, > rather than one of th

Re: [Python-Dev] (no subject)

Antoine Pitrou wrote: bytearray(b"a") + b"bc" bytearray(b'abc') b"a" + bytearray(b"bc") b'abc' It's quite convenient. It's a bit disconcerting that the left operand wins, rather than one of them being designated as the "wider" type, as occurs with many other operations on mixed types, e.

Re: [Python-Dev] (no subject)

+1 for adding "+" or "|" operator for merging dicts. To me this operation: >>> {'x': 1, 'y': 2} + {'z': 3} {'x': 1, 'y': 2, 'z': 3} Is very clear. The only potentially non obvious case I can see then is when there are duplicate keys, in which case the syntax could just be defined that last sette

Re: [Python-Dev] (no subject)

Victor Stinner wrote: Le 10 févr. 2015 06:48, "Greg Ewing" > a écrit : > It could potentially be a little more efficient by > eliminating the construction of an intermediate list. Is it the case in the implementation? If it has to create a temporary list/tu

Re: [Python-Dev] (no subject)

Donald Stufft wrote: 1. The statement *item is roughly the same thing as (item[0], item[1], item[n]) No, it's not -- that would make it equivalent to tuple(item), which is not what it means in any of its existing usages. What it *is* roughly equivalent to is item[0], item[1], item[n] i.e

Re: [Python-Dev] (no subject)

On 10/02/2015 13:23, Antoine Pitrou wrote: On Tue, 10 Feb 2015 23:16:38 +1000 Nick Coghlan wrote: On 10 Feb 2015 19:24, "Terry Reedy" wrote: On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is telling "this is a read-only mirror"

Re: [Python-Dev] (no subject)

On 10 Feb 2015 19:41, "Paul Moore" wrote: > > I agree completely with Donald here. The comprehension syntax has > consistently been the part of the proposal that has resulted in > confused questions from reviewers, and I don't think it's at all > intuitive. > > Is it allowable to vote on parts of

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 23:16:38 +1000 Nick Coghlan wrote: > On 10 Feb 2015 19:24, "Terry Reedy" wrote: > > > > On 2/9/2015 7:29 PM, Neil Girdhar wrote: > >> > >> For some reason I can't seem to reply using Google groups, which is is > >> telling "this is a read-only mirror" (anyone know why?) > > >

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 1:33 AM, Paul Moore wrote: > On 10 February 2015 at 00:29, Neil Girdhar wrote: > >> > function(**kw_arguments, **more_arguments) > >> If the key "key1" is in both dictionaries, more_arguments wins, right? > > > > > > There was some debate and it was decided that duplicate

Re: [Python-Dev] (no subject)

On 10 Feb 2015 19:24, "Terry Reedy" wrote: > > On 2/9/2015 7:29 PM, Neil Girdhar wrote: >> >> For some reason I can't seem to reply using Google groups, which is is >> telling "this is a read-only mirror" (anyone know why?) > > > I presume spam prevention. Most spam on python-list comes from the

Re: [Python-Dev] (no subject)

On 10 February 2015 at 01:48, Donald Stufft wrote: > I am really really -1 on the comprehension syntax. [... omitting because gmail seems to have messed up the quoting ...] > I don’t think * means “loop” anywhere else in Python and I would never > “guess” that [*item for item in iterable] meant

Re: [Python-Dev] (no subject)

On 10 February 2015 at 00:29, Neil Girdhar wrote: >> > function(**kw_arguments, **more_arguments) >> If the key "key1" is in both dictionaries, more_arguments wins, right? > > > There was some debate and it was decided that duplicate keyword arguments > would remain an error (for now at least). I

Re: [Python-Dev] (no subject)

On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is telling "this is a read-only mirror" (anyone know why?) I presume spam prevention. Most spam on python-list comes from the read-write GG mirror. -- Terry Jan Reedy __

Re: [Python-Dev] (no subject)

On Mon, 09 Feb 2015 18:06:02 -0800 Ethan Furman wrote: > On 02/09/2015 05:14 PM, Victor Stinner wrote: > > > > def partial(func, *args, **keywords): > > def newfunc(*fargs, **fkeywords): > > return func(*(args + fargs), **keywords, **fkeywords) > > ... > > return newfunc > >

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 19:04:03 +1300 Greg Ewing wrote: > Donald Stufft wrote: > > > > perhaps a better > > solution is to simply make it so that something like ``a_list + > > an_iterable`` is valid and the iterable would just be consumed and +’d > > onto the list. > > I don't think I like the a

Re: [Python-Dev] (no subject)

On 10.02.15 04:06, Ethan Furman wrote: return func(*(args + fargs), **{**keywords, **fkeywords}) We don't use [*args, *fargs] for concatenating lists, but args + fargs. Why not use "+" or "|" operators for merging dicts? ___ Python-Dev mailin

Re: [Python-Dev] (no subject)

Le 10 févr. 2015 06:48, "Greg Ewing" a écrit : > It could potentially be a little more efficient by > eliminating the construction of an intermediate list. Is it the case in the implementation? If it has to create a temporary list/tuple, I will prefer to not use it. After long years of developme

Re: [Python-Dev] (no subject)

ah, sorry… forget that I said "just as it is now" — I am losing track of what's allowed in Python now! On Tue, Feb 10, 2015 at 2:29 AM, Neil Girdhar wrote: > > > On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner > wrote: > >> To be logic, I expect [(*item) for item in mylist] to simply return >>

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner wrote: > To be logic, I expect [(*item) for item in mylist] to simply return mylist. > If you want simply mylist as a list, that is [*mylist] > [*(item) for item in mylist] with mylist=[(1, 2), (3,)] could return [1, > 2, 3], > right > as just [*

Re: [Python-Dev] (no subject)

To be logic, I expect [(*item) for item in mylist] to simply return mylist. [*(item for item in mylist] with mylist=[(1, 2), (3,)] could return [1, 2, 3], as just [*mylist], so "unpack" mylist. Victor ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 2:08 AM, Victor Stinner wrote: > > Le 10 févr. 2015 03:07, "Ethan Furman" a écrit : > > That line should read > > > > return func(*(args + fargs), **{**keywords, **fkeywords}) > > > > to avoid the duplicate key error and keep the original functionality. > > To me, thi

Re: [Python-Dev] (no subject)

Le 10 févr. 2015 03:07, "Ethan Furman" a écrit : > That line should read > > return func(*(args + fargs), **{**keywords, **fkeywords}) > > to avoid the duplicate key error and keep the original functionality. To me, this is just ugly. It prefers the original code which use .update(). Maybe t

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 1:31 AM, Donald Stufft wrote: > > > On Feb 10, 2015, at 12:55 AM, Greg Ewing > wrote: > > > > Donald Stufft wrote: > >> However [*item for item in ranges] is mapped more to something like > this: > >> result = [] > >> for item in iterable: > >>result.extend(*item) > >

Re: [Python-Dev] (no subject)

> On Feb 10, 2015, at 12:55 AM, Greg Ewing wrote: > > Donald Stufft wrote: >> However [*item for item in ranges] is mapped more to something like this: >> result = [] >> for item in iterable: >>result.extend(*item) > > Actually it would be > > result.extend(item) > > But if that bothers

Re: [Python-Dev] (no subject)

Donald Stufft wrote: perhaps a better solution is to simply make it so that something like ``a_list + an_iterable`` is valid and the iterable would just be consumed and +’d onto the list. I don't think I like the asymmetry that this would introduce into + on lists. Currently [1, 2, 3] +

Re: [Python-Dev] (no subject)

Donald Stufft wrote: However [*item for item in ranges] is mapped more to something like this: result = [] for item in iterable: result.extend(*item) Actually it would be result.extend(item) But if that bothers you, you could consider the expansion to be result = [] for item in itera

Re: [Python-Dev] (no subject)

Donald Stufft wrote: why is: print(*[1], *[2], 3) better than print(*[1] + [2] + [3])? It could potentially be a little more efficient by eliminating the construction of an intermediate list. defining + or | or some other symbol for something similar to [1] + [2] but for dictionaries. This

Re: [Python-Dev] (no subject)

On 02/09/2015 05:48 PM, Donald Stufft wrote: > > I don’t think * means “loop” anywhere else in Python and I would never > “guess” that > > [*item for item in iterable] > > meant that. It’s completely non intuitive. Anywhere else you see *foo it’s > unpacking a tuple not making an inner loop.

Re: [Python-Dev] (no subject)

On 02/09/2015 05:14 PM, Victor Stinner wrote: > > def partial(func, *args, **keywords): > def newfunc(*fargs, **fkeywords): > return func(*(args + fargs), **keywords, **fkeywords) > ... > return newfunc > > The new code behaves differently since Neil said that an error is > ra

Re: [Python-Dev] (no subject)

> On Feb 9, 2015, at 8:34 PM, Neil Girdhar wrote: > > > > On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft > wrote: > >> On Feb 9, 2015, at 7:29 PM, Neil Girdhar > > wrote: >> >> For some reason I can't seem to reply using Google groups, w

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft wrote: > > On Feb 9, 2015, at 7:29 PM, Neil Girdhar wrote: > > For some reason I can't seem to reply using Google groups, which is is > telling "this is a read-only mirror" (anyone know why?) Anyway, I'm going > to answer as best I can the concerns.

Re: [Python-Dev] (no subject)

2015-02-10 1:29 GMT+01:00 Neil Girdhar : > For some reason I can't seem to reply using Google groups, which is is > telling "this is a read-only mirror" (anyone know why?) Anyway, I'm going > to answer as best I can the concerns. > > Antoine said: > >> To be clear, the PEP will probably be useful

Re: [Python-Dev] (no subject)

Just an FYI: http://www.reddit.com/r/Python/comments/2v8g26/python_350_alpha_1_has_been_released/ 448 was mentioned here (by Python lay people — not developers). On Mon, Feb 9, 2015 at 7:56 PM, Neil Girdhar wrote: > The admonition is against syntax that currently exists. > > On Mon, Feb 9, 2015

Re: [Python-Dev] (no subject)

The admonition is against syntax that currently exists. On Mon, Feb 9, 2015 at 7:53 PM, Barry Warsaw wrote: > On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote: > > >Also, regarding calling argument order, not any order is allowed. Regular > >arguments must precede other kinds of arguments. Key

Re: [Python-Dev] (no subject)

On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote: >Also, regarding calling argument order, not any order is allowed. Regular >arguments must precede other kinds of arguments. Keyword arguments must >precede **-args. *-args must precede **-args. However, I agree with >Antoine that PEP 8 should

Re: [Python-Dev] (no subject)

> On Feb 9, 2015, at 7:29 PM, Neil Girdhar wrote: > > For some reason I can't seem to reply using Google groups, which is is > telling "this is a read-only mirror" (anyone know why?) Anyway, I'm going to > answer as best I can the concerns. > > Antoine said: > > To be clear, the PEP will pr

Re: [Python-Dev] (no subject)

Yes, that's exactly right. It does not affect the callee. Regarding function call performance, nothing has changed for the originally accepted argument lists: the opcodes generated are the same and they are processed in the same way. Also, regarding calling argument order, not any order is allow

Re: [Python-Dev] (no subject)

What's an example of a way inspect.signature must change? I thought PEP 448 added new unpacking shortcuts which (for example) change the *caller* side of a function call. I didn't realize it impacted the *callee* side too. //arry/ On 02/09/2015 03:14 PM, Antoine Pitrou wrote: On Tue, 1

Re: [Python-Dev] (no subject)

For some reason I can't seem to reply using Google groups, which is is telling "this is a read-only mirror" (anyone know why?) Anyway, I'm going to answer as best I can the concerns. Antoine said: To be clear, the PEP will probably be useful for one single line of > Python code every 1. This

Re: [Python-Dev] (no subject)

> On Feb 9, 2015, at 4:06 PM, Neil Girdhar wrote: > > Hello all, > > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/ > ) is implemented now based on some > early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently >

Re: [Python-Dev] (no subject) PEP 448

2015-02-10 0:51 GMT+01:00 Antoine Pitrou : >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is >> implemented now based on some early work by Thomas Wouters (in 2008) and >> Florian Hahn (2013) and recently completed by Joshua Landau and me. > > To be clear, the PEP will probably

Re: [Python-Dev] (no subject) PEP 448

On Mon, 9 Feb 2015 16:06:20 -0500 Neil Girdhar wrote: > Hello all, > > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is > implemented now based on some early work by Thomas Wouters (in 2008) and > Florian Hahn (2013) and recently completed by Joshua Landau and me. To be clear,

Re: [Python-Dev] (no subject)

Hi, 2015-02-09 22:06 GMT+01:00 Neil Girdhar : > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is > implemented now based on some early work by Thomas Wouters (in 2008) and > Florian Hahn (2013) and recently completed by Joshua Landau and me. I don't like this PEP. IMO it makes t

Re: [Python-Dev] (no subject)

That wording is my fault. I'll update the PEP to remove the word "currently" after waiting a bit to see if there are any other problems. Best, Neil On Mon, Feb 9, 2015 at 6:16 PM, Benjamin Peterson wrote: > > > On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote: > > Right, > > > > Just to be c

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote: > Right, > > Just to be clear though: **-args must follow any *-args and position > arguments. So at worst, your example is: > > f(x, y, *k, *b, c, **w, **d) > > Best, Ah, I guess I was confused by this sentence in the PEP: " Function call

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 08:43:53 +1000 Nick Coghlan wrote: > > For example, the potential for arcane call arguments suggests the need for > a PEP 8 addition saying "first standalone args, then iterable expansions, > then mapping expansions", even though syntactically any order would now be > permitte

Re: [Python-Dev] (no subject)

Right, Just to be clear though: **-args must follow any *-args and position arguments. So at worst, your example is: f(x, y, *k, *b, c, **w, **d) Best, Neil On Mon, Feb 9, 2015 at 5:10 PM, Benjamin Peterson wrote: > > > On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote: > > FWIW, I've

Re: [Python-Dev] (no subject)

On 10 Feb 2015 08:13, "Benjamin Peterson" wrote: > > > > On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote: > > On 02/09/2015 01:28 PM, Benjamin Peterson wrote: > > > On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: > > >> > > >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote: > On 02/09/2015 01:28 PM, Benjamin Peterson wrote: > > On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: > >> > >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is > >> implemented now based on some early work by Thomas Wouters

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote: > FWIW, I've encouraged Neil and others to complete this code as a > prerequisite for a code review (but I can't review it myself). I am > mildly > in favor of the PEP -- if the code works and looks maintainable I would > accept it. (A few th

Re: [Python-Dev] (no subject)

On 02/09/2015 01:28 PM, Benjamin Peterson wrote: > On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: >> >> The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is >> implemented now based on some early work by Thomas Wouters (in 2008) and >> Florian Hahn (2013) and recently completed by

Re: [Python-Dev] (no subject)

FWIW, I've encouraged Neil and others to complete this code as a prerequisite for a code review (but I can't review it myself). I am mildly in favor of the PEP -- if the code works and looks maintainable I would accept it. (A few things got changed in the PEP as a result of the work.) On Mon, Feb

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: > Hello all, > > The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is > implemented now based on some early work by Thomas Wouters (in 2008) and > Florian Hahn (2013) and recently completed by Joshua Landau and me. > > The issue t

Re: [Python-Dev] (no subject)

Am 19.04.2012 10:00, schrieb Eric Snow: > How closely is tokenize.detect_encoding() supposed to match > PyTokenizer_FindEncoding()? From what I can tell, there is a subtle > difference in their behavior that has bearing on PEP 263 handling > during import. [1] Should any difference be considered

Re: [Python-Dev] (no subject)

The authors are definitely interested in feedback! Best probably to post it to my G+ thread. On Mon, Dec 12, 2011 at 1:44 PM, Eric Snow wrote: > Guido posted this on Google+: > >> IEEE/ISO are working on a draft document about Python vulunerabilities: >> http://grouper.ieee.org/groups/plv/DocLog

Re: [Python-Dev] (no subject)

Bug reports should be filed at bugs.python.org On Mon, Jan 24, 2011 at 08:39, Stefan Spoettl wrote: > Using: > Python 2.7.0+ (r27:82500, Sep 15 2010, 18:14:55) > [GCC 4.4.5] on linux2 > (Ubuntu 10.10) > Method to reproduce error: > 1. Defining a module which is later imported by another: > --

Re: [Python-Dev] (no subject)

On Mon, Jan 24, 2011 at 04:39:54PM +, Stefan Spoettl wrote: > So it may be that the Python interpreter isn't working correctly onlyon > Ubuntu 10.10 Than you should report the problem to the Ubuntu developers, right? And it would be nice if you investigate deeper and send a proper mail - w

Re: [Python-Dev] (no subject)

Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/

Re: [Python-Dev] (no subject)

Hi! This mailing list is about developing Python itself, not about developing *in* Python or debugging Python installations. Try seeing help elsewhere, such as on the comp.lang.python newsgroup, #python IRC channel on freenode, or other sources (check the wiki if you need any others). Thanks, l

Re: [Python-Dev] (no subject)

On Mon 15/03/10 4:34 AM , "Martin v. Löwis" mar...@v.loewis.de sent: > > So, just to be clear about the my bug report, it > is directly related> to the problem of overlapping I/O requests with > CPU-bound processing.> This kind of scenario comes up in the context of > many> applications--especia

Re: [Python-Dev] (no subject)

Martin v. Löwis v.loewis.de> writes: > > > What do you think of creating a "buildbot" category in the tracker? There > > are > > often problems on specific buildbots which would be nice to track, but there's > > nowhere to do so. > > Do you have any specific reports that you would want to class

Re: [Python-Dev] (no subject)

On 4/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > JOSHUA ABRAHAM wrote: > > I was hoping you guys would consider creating function in os.path or > > otherwise that would find the full path of a file when given only it's base > > name and nothing else.I have been made to understand that this is n

Re: [Python-Dev] (no subject)

JOSHUA ABRAHAM wrote: > I was hoping you guys would consider creating function in os.path or > otherwise that would find the full path of a file when given only it's base > name and nothing else.I have been made to understand that this is not > currently possible. Does os.path.abspath() do wha

Re: [Python-Dev] (no subject)

On 11/24/05, Duncan Grisby <[EMAIL PROTECTED]> wrote: > Hi, > > I posted this to comp.lang.python, but got no response, so I thought I > would consult the wise people here... > > I have encountered a problem with the re module. I have a > multi-threaded program that does lots of regular expression

Re: [Python-Dev] (no subject)

Donovan Baarda wrote: > I don't know if this will help, but in my experience compiling re's > often takes longer than matching them... are you sure that it's the > match and not a compile that is taking a long time? Are you using > pre-compiled re's or are you dynamically generating strings and us

Re: [Python-Dev] (no subject)

On Thu, 2005-11-24 at 14:11 +, Duncan Grisby wrote: > Hi, > > I posted this to comp.lang.python, but got no response, so I thought I > would consult the wise people here... > > I have encountered a problem with the re module. I have a > multi-threaded program that does lots of regular express

Re: [Python-Dev] (no subject)

Hi Rijish- The python-dev list is for developers *of* python, not for people developing *with* python. I'd recommend you post this on the python-list, but I see you already have. You'll find they can be very helpful, if you show that you've done some research, and ask a specific question. A sub

Re: [Python-Dev] (no subject)

Phillip J. Eby wrote: At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote: Does deciding whether or not to supply the function really need to be dependent on whether or not a format for __signature__ has been chosen? Um, no. Why would you think that? Pronoun confusion. I interpreted an 'it' in your mes

Re: [Python-Dev] (no subject)

At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote: Phillip J. Eby wrote: I discussed this approach with Guido in private e-mail a few months back during discussion about an article I was writing for DDJ about decorators. We also discussed something very similar to 'update_meta()', but never settled

Re: [Python-Dev] (no subject)

Phillip J. Eby wrote: I discussed this approach with Guido in private e-mail a few months back during discussion about an article I was writing for DDJ about decorators. We also discussed something very similar to 'update_meta()', but never settled on a name. Originally he wanted me to PEP th

Re: [Python-Dev] (no subject)

Phillip J. Eby wrote: [SNIP] One solution is to have a __signature__ attribute that's purely documentary. That is, modifying it wouldn't change the function's actual behavior, so it could be copied with update_meta() but then modified by the decorator if need be. __signature__ would basically

Re: [Python-Dev] (no subject)

At 04:35 PM 3/14/05 +0100, Thomas Heller wrote: Another possibility (ugly, maybe) would be to create sourcecode with the function signature that you need, and compile it. inspect.getargspec() and inspect.formatargspec can do most of the work. I've done exactly that, for generic functions in PyProto

Re: [Python-Dev] (no subject)

"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > At 05:34 AM 3/14/05 -0800, Michael Chermside wrote: >>Nice... thanks. But I have to ask: is this really the right set of metadata to >> be updating? Here are a few things that perhaps ought be copied by >> update_meta: >> >> f.__name__ (alread

Re: [Python-Dev] (no subject)

At 05:34 AM 3/14/05 -0800, Michael Chermside wrote: Nice... thanks. But I have to ask: is this really the right set of metadata to be updating? Here are a few things that perhaps ought be copied by update_meta: f.__name__ (already included) f.__doc__ (already included) f.__di